aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/feature/feature.h
AgeCommit message (Collapse)AuthorFilesLines
2021-11-19fib: Don't use [midchain] adjacencies to change an interface's feature arcNeale Ranns1-0/+4
Type: fix Using the adjacency to modify the interface's feature arc doesn't work, since there are potentially more than one adj per-interface. Instead have the interface, when it is created, register what the end node of the feature arc is. This end node is then also used as the interface's tx node (i.e. it is used as the adjacency's next-node). rename adj-midhcain-tx as 'tunnel-output', that's a bit more intuitive. There's also a fix in config string handling to: 1- prevent false sharing of strings when the end node of the arc is different. 2- call registered listeners when the end node is changed For IPSec the consequences are that one cannot provide per-adjacency behaviour using different end-nodes - this was previously done for the no-SA and an SA with no protection. These cases are no handled in the esp-encrypt node. Signed-off-by: Neale Ranns <neale@graphiant.com> Change-Id: If3a83d03a3000f28820d9a9cb4101d244803d084
2020-07-29feature: add vnet_feature_is_enabledDave Barach1-0/+4
A predicate function which says whether a given sw_if_index has a certain feature enabled. int vnet_feature_is_enabled (const char *arc_name, const char *feature_node_name, u32 sw_if_index) returns 1 if the feature is enabled returns 0 if the feature is not enabled returns VNET_API_ERROR_INVALID_VALUE if the arc name is not found returns VNET_API_ERROR_INVALID_VALUE_2 if the feature node name is not found returns VNET_API_ERROR_INVALID_SW_IF_INDEX if the sw_if_index is not found Type: improvement Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Id9ed53e2ae9252efc750ae80fd610456b95cefa4
2020-05-13feature: Config end nodes are user specificNeale Ranns1-1/+1
Type: fix it is possible for a user to change the end node of a feature arc, but this change should only apply to that 'instnace' of the arc, not all arcs. for example, if a tunnel has its ipx-output end node changed to adj-midchain-tx, this shouldn't affect all ipx-output arcs. obviously... Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I41daea7ba6907963e42140307d065c8bcfdcb585
2020-05-04fib: midchain adjacency optimisationsNeale Ranns1-0/+20
Type: improvement - inline some common encap fixup functions into the midchain rewrite node so we don't incur the cost of the virtual function call - change the copy 'guess' from ethernet_header (which will never happen) to an ip4 header - add adj-midchain-tx to multiarch sources - don't run adj-midchain-tx as a feature, instead put this node as the adj's next and at the end of the feature arc. - cache the feature arc config index (to save the cache miss going to fetch it) - don't check if features are enabled when taking the arc (since we know they are) the last two changes will also benefit normal adjacencies taking the arc (i.e. for NAT, ACLs, etc) for IPSec: - don't run esp_encrypt as a feature, instead when required insert this node into the adj's next and into the end of the feature arc. this implies that encrypt is always 'the last feature' run, which is symmetric with decrypt always being the first. - esp_encrpyt for tunnels has adj-midchain-tx as next node Change-Id: Ida0af56a704302cf2d7797ded5f118a781e8acb7 Signed-off-by: Neale Ranns <nranns@cisco.com>
2020-02-25feature: provide a u16 version of vnet_feature_nextNeale Ranns1-0/+8
Type: improvement when using vlib_buffer_enqueue_to_next the 'nexts' parameter is an array of u16, but vnet_feautre_next takes a u32. this is a simple wrapper to address the impedence mismatch. Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I0fa86629e979e313344eb68442dc35a7b9537a8f
2019-12-03fib feature: Code mechanics to decouple dependency of feature on adjNeale Ranns1-0/+6
Type: refactor Signed-off-by: Neale Ranns <nranns@cisco.com> Change-Id: I1d8b88fe1eefc850865297b4f025b97e6373a6bd
2019-11-25vlib: autogenerate <node> before <last-in-arc> constraintsDave Barach1-0/+1
If an arc declaration includes '.last_in_arc = "some-node"', assume that folks mean it and add explicit ordering constraints. Fix the "arp" arc declaration which claimed that the arc ends at arp-disabled, but the arc really ends at error-drop. Type: fix Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: Ie2de1fb30091671cbc7c62770903a2e05987f141
2019-10-16bonding: graph node running after bond-input in feature arc may crashSteven Luong1-0/+7
In bond RX quad loop, when all packets within the frame have the same incoming interface, we cannot skip calling bond_update_next because that function calls vnet_feature_next() to update the b->current_config_index. The next node needs the correct b->current_config_index to work with. Type: fix Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I3d8b3d4e0f95490f406fae7638f0c43c301ce664
2018-11-26Add a feature arc consistency checkDave Barach1-0/+2
Verify that last node in the computed feature order matches reality. This check doesn't make sense in all cases, so we skip it if the newly-added vnet_feature_arc_registration_t ".last_in_arc" datum is a NULL pointer. Change-Id: Ia99c3e2b2da2e4780a7d5bc71670c5742a66fef2 Signed-off-by: Dave Barach <dave@barachs.net>
2018-11-19Improve feature arc order constraint specificationDave Barach1-6/+55
Add the VNET_FEATURE_ARC_ORDER macro, which allows specification of bulk order constraints. Here's an example: VNET_FEATURE_ARC_ORDER(ip4_unicast_arc_order, static) = { .arc_name = "ip4-unicast", .node_names = VNET_FEATURES ("ip4-flow-classify", "ip4-inacl", "ip4-source-check-via-rx", "ip4-source-check-via-any", "ip4-source-and-port-range-check-rx", "ip4-policer-classify", "ipsec4-input", "vpath-input-ip4", "ip4-vxlan-bypass", "ip4-not-enabled", "ip4-lookup"), }; Simply list feature nodes in the desired order, and you're done. Multiple macro instances per are are fine / expected / tested. Under the covers: generate "a before b" tuples by chain-dragging across the ordered list. No need to touch existing per-feature constraints. Fixed a long-broken "you lose!" error message. Change-Id: I259282e426fd305e22c8d65886787c41a1d348d3 Signed-off-by: Dave Barach <dave@barachs.net>
2018-08-13Multiarch handling in different constructor macrosDamjan Marion1-0/+9
This significantly reduces need for ... in multiarch code. Simply constructor macros will jost create static unused entry if CLIB_MARCH_VARIANT is defined and that will be optimized out by compiler. Change-Id: I17d1c4ac0c903adcfadaa4a07de1b854c7ab14ac Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-07-19Remove unused argument to vlib_feature_nextDamjan Marion1-4/+4
Change-Id: Ieb8b53977fc8484c19780941e232ee072b667de3 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-07-19Cleanup of handoff codeDamjan Marion1-14/+0
- removed handoff-dispatch node - removed some unused buffer metadata fields - enqueue to thread logic moved to inline function Change-Id: I7361e1d88f8cce74cd4fcec90d172eade1855cbd Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-05-27VPP-1294: add missing feature arc constraintDave Barach1-1/+2
the ip4-dhcp-client-detect feature MUST run prior to nat44-out2in, or inbound dhcp broadcast packets will be dropped. Certain dhcp servers answer lease renewal dhcp-request packets with broadcast dhcp-acks, leading to unrecoverable lease loss. In detail, this constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa"), }; doesn't get the job done: ip4-unicast: [17] nat44-out2in [23] ip4-dhcp-client-detect [26] ip4-not-enabled Add a proper constraint: VNET_FEATURE_INIT (ip4_snat_out2in, static) = { .arc_name = "ip4-unicast", .node_name = "nat44-out2in", .runs_after = VNET_FEATURES ("acl-plugin-in-ip4-fa", "ip4-dhcp-client-detect"), }; and the interface feature order is OK, at least in this regard: ip4-unicast: [17] ip4-dhcp-client-detect [18] nat44-out2in [26] ip4-not-enabled We need to carefully audit (especially) the ip4-unicast feature arc, which has [gasp] 37 features on it! Change-Id: I5e749ead7ab2a25d80839a331de6261e112977ad Signed-off-by: Dave Barach <dave@barachs.net>
2018-04-27A bit of buffer metadata reshuffling to accommodate flow_idDamjan Marion1-9/+9
Change-Id: I2794384557c6272fe217269b14a9db09eda19220 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-04-09features: don't break linked list, create separate one for arcDamjan Marion1-1/+1
We need to keep original linked list so destructire can remove entries. Change-Id: I5ff5ca0e1a417d88707255207725bba46433c943 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-04-09plugins: unload plugin if early init failsDamjan Marion1-0/+16
Change-Id: I32f68e2ee8f5d32962acdefb0193583f71d342b3 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-02-26vnet: add vnet_device_input_have_features functionDamjan Marion1-0/+7
Change-Id: I28cfa7f7f5e4938146478c4a5cc5ad18612aadaa Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-03-17Fix IP feature ordering.Neale Ranns1-3/+0
Drop comes before lookup when enabled. is_first_or_last is not required when setting a feature, the anchor is added in find_config_with_features(). Don't make the PG interfaces automatically L3 enabled, this way we can have tests that check the L3 protocol disbaled behaviour. Change-Id: Icef22a920b27ff9cec6ab2da6b05f05c532cb60f Signed-off-by: Neale Ranns <nranns@cisco.com>
2017-03-06features: take device-input buffer advance value directlyDamjan Marion1-27/+35
Change-Id: Ifac7d9134d03d79164ce6f06ae9413279bbaadb3 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+382
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>