The discussion about feature arcs is a red herring with respect to the buffer enqueue dance. It's about node A enqueueing to its successor nodes B, C, D, etc. It's the same whether or not A (and friends) are part of a feature arc. The feature arc code manages the set of successor nodes, and has little-to-nothing to do with vector element enqueue mechanics.
The 1x/2x speculative enqueue scheme makes the observation that with high probability packets i and i+1 (and i+2 in the _x2 case) will be enqueued to the same successor node. Notice the PREDICT_FALSE in the macro. Next_index is the current arc index. In the PREDICT_FALSE case, the current packet isn't to follow the same arc that the last vector element followed. In that case, the macro unwinds the speculative enqueue done near the top of the loop, sends the packet along the correct arc, and changes the current arc index; next_index. HTH... Dave From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Nitin Saxena Sent: Friday, February 8, 2019 6:36 AM To: Gudimetla, Leela Sankar <lgudi...@ciena.com>; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Understanding vlib_buffer_enqueue() If yes, why the frame needs to traverse two directions? Should it not traverse only feature-arc? The flow is in one direction only. Every node has speculated "next_index" node. If the speculated "next_index" node is not same as actual "next0" node (which is typically retrieved by either parsing data or vlib buffer). So if speculated "next_index" node is not same as actual "next0" node, release/put the frame of "next_index" node and get the frame corresponding to "next0" node. Also make "next0" as "next_index" node (considering further packets will come corresponding to this "next_index" node). Thanks, Nitin ________________________________________ From: mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> on behalf of Gudimetla, Leela Sankar <mailto:lgudi...@ciena.com> Sent: Friday, February 8, 2019 9:23 AM To: mailto:vpp-dev@lists.fd.io Subject: [vpp-dev] Understanding vlib_buffer_enqueue() External Email Hello, I am trying to understand a piece of code that enqueues a frame to next-node. But when a frame is traversing feature-nodes, I see the following boiler-plate code that seems to be sending the frames to two nodes at the same time. Is my understanding correct? 218 #define vlib_validate_buffer_enqueue_x1(vm,node,next_index,to_next,n_left_to_next,bi0,next0) \ 219 do { \ 220 if (PREDICT_FALSE (next0 != next_index)) \ 221 { \ 222 vlib_put_next_frame (vm, node, next_index, n_left_to_next + 1); \ 223 next_index = next0; \ 224 vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next); \ 225 \ 226 to_next[0] = bi0; \ 227 to_next += 1; \ 228 n_left_to_next -= 1; \ 229 } \ 230 } while (0) If yes, why the frame needs to traverse two directions? Should it not traverse only feature-arc? Any pointers in understanding would really help. Thanks, Leela sankar
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12218): https://lists.fd.io/g/vpp-dev/message/12218 Mute This Topic: https://lists.fd.io/mt/29698182/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
