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: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> on behalf of Gudimetla, Leela
Sankar <lgudi...@ciena.com>
Sent: Friday, February 8, 2019 9:23 AM
To: 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 (#12217): https://lists.fd.io/g/vpp-dev/message/12217
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]
-=-=-=-=-=-=-=-=-=-=-=-
