Vnet_feature_arc_start initializes b->current_config_index and next0 if and only if features are active on the arc.
Take a look at src/vnet/ip/ip_punt_drop.h, which explicitly (and correctly!) sets next0...next3 to zero, or src/vnet/dpo/dvr_dpo.c which sets next0..1 to zero. As in: if no features are active on the arc, these codes (and presumably any correct code) will send the packet to .next_nodes[0]. Up to the point where one calls e.g. vlib_validate_buffer_enqueue_xN() - or vlib_buffer_enqueue_to_next() depending on dispatch style - the code can change its mind about nextN. Do yourself a favor: build a -g -O0 image, configure some features e.g. on a packet-generator interface, push packets into the head of the configured feature arc, step through the head of feature arc and feature node code in gdb. Look at the output of "show vlib graph" carefully. You'll see that the feature code adds graph arcs with indices above those of static .next_node arcs. D. From: [email protected] <[email protected]> On Behalf Of Catalin Vasile Sent: Thursday, April 15, 2021 5:59 PM To: [email protected]; [email protected] Subject: Re: [vpp-dev] Feature Arcs Hi, I've went through wiki before asking the questions. 2. Does ".next_nodes" from VLIB_REGISTER_NODE() restrain to which nodes the .function() primitive may send it to? >>> DB: explicit .next_nodes are used to divert packets off a given feature arc. Typical use-case: send non-compliant frames to error-drop. The feature arc mechanism adds additional next-node indices (next0..3 values) which correspond to the next enabled feature on the feature arc. >>> CV: vnet_feature_arc_start() seems to actually trigger the send, and there is a "next" argument that says explicitly where to send them. What roles does the ".next_nodes" have if the programmer still explicitly tells it? When you say "off a given feature arc" you are saying when the traffic/packets start to get outside of that arc? _____ From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Sent: Thursday, April 15, 2021 14:47 To: Catalin Vasile <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: RE: [vpp-dev] Feature Arcs Please see https://fd.io/docs/vpp/master/gettingstarted/developers/featurearcs.html. Also, see inline below From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of Catalin Vasile Sent: Thursday, April 15, 2021 6:17 AM To: [email protected] <mailto:[email protected]> Subject: [vpp-dev] Feature Arcs Hi, I'm trying to grasp how features arcs are done in the code. And have a couple of questions 1. Is a feature a representation of a node ? >>> DB: I would put it this way: nodes implement features 2. Does ".next_nodes" from VLIB_REGISTER_NODE() restrain to which nodes the .function() primitive may send it to? >>> DB: explicit .next_nodes are used to divert packets off a given feature arc. Typical use-case: send non-compliant frames to error-drop. The feature arc mechanism adds additional next-node indices (next0..3 values) which correspond to the next enabled feature on the feature arc. 3. I'm trying to grasp how the feature arhitecture has been thought. I started by looking the "nsh" plugin. >From what I understand: VNET_FEATURE_ARC_INIT() creates an empty Arc of nodes/features .start_nodes from VNET_FEATURE_ARC_INIT() says/adds where the Arc processing starts VNET_FEATURE_INIT() adds nodes/features to the Arc .runs_before from VNET_FEATURE_INIT() and .next_nodes from VLIB_REGISTER_NODE() give the vertices/dependencies in the Arc Everything in "nsh" seems to start from the "nsh_midchain_node" node. How is the "nsh_eth_output_node" triggered? I see it has the same name as the Arc name ("nsh-eth-output"). Does this have any relevance or it is just a coincidence of name? Does a node which belongs to no Arc get triggered directly with no dependency? 4. It is not clear to me who initializes the "nm->output_feature_arc_index" entry. >>> DB: it is suspicious that the VNET_FEATURE_INIT(...) macro doesn't include ".arc_index_ptr = &nm.output_feature_arc_index": /* Built-in nsh tx feature path definition */ VNET_FEATURE_INIT (nsh_interface_output, static) = { .arc_name = "nsh-eth-output", .node_name = "interface-output", .runs_before = 0, /* not before any other features */ }; Might ask the nsh maintainers [see <wsroot>/MAINTAINERS] about that. Best regards, Catalin Vasile
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19218): https://lists.fd.io/g/vpp-dev/message/19218 Mute This Topic: https://lists.fd.io/mt/82113339/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
