Thanks Dave and Damjan, If I understand correctly a node can add elements to a frame and the pending frame thus formed are put into the graph dispatcher's run-queue.
Checking the structure of vlib_pending_frame_t, there is a param 'next_frame_index. Does it mean that we can have a list of pending frames in a node at a time (max 256 packets in each frame). If there is a pending frame, is it processed just like a normal frame? Reading through the code, I get a feel that pending frames are not processed the way normal frames are, and there are some timer wheel involved, but could not figure out the exact mechanism. Thanks and Regards, Raj On Fri, Feb 1, 2019 at 8:21 PM Dave Barach (dbarach) <dbar...@cisco.com> wrote: > > Next frames are the physical manifestations of graph arcs. Pending frames are > graph scheduler run-queue entries. > > -----Original Message----- > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Raj > Sent: Friday, February 1, 2019 9:47 AM > To: vpp-dev <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] Understanding vlib_frame_t > > Thanks Damjan and Dave. These small explanations will greatly help in making > sure what I understand from reading code is correct. > > Just a couple of followup questions, I hope these will help those reading the > archives later too in understanding the nuances of VPP architecture. > > vlib_get_buffer() translates the buffer index into buffer pointer. > Where exactly is the buffer memory getting allocated, when packets are coming > in via dpdk-input? Is this allocation is done by DPDK or this is done by VPP. > If I understand correctly vlib_buffer_t is pointing to this location. > > Also as I understand, a graph nodes gets a vector. This vector is a frame > which holds a set of 4 Byte buffer indices which points to the the actual > buffer, containing packets. Node process all these packets (max 256) and > transmit to the next node. While reading code in this area, after processing > this there is reference to next frame and pending frame. I could not figure > out what these are and for what they are being used. > > Thanks and Regards, > > Raj > > On Thu, Jan 31, 2019 at 9:31 PM Dave Barach (dbarach) <dbar...@cisco.com> > wrote: > > > > In vlib – vpp’s basic vector library - frames comprise a single vector, a > > set of scalar variables, and some flags. > > > > > > > > At node creation time, each graph node registration indicates the size of a > > vector element, and the total size of scalar data. Vlib_frame_t vectors > > include up to VLIB_FRAME_SIZE (256) vector elements of the indicated size. > > > > > > > > In the vpp/vnet use case, vector elements are 32-bit buffer handles, easily > > converted to vlib_buffer_t pointers. Most graph nodes do not use scalar > > data. > > > > > > > > An sample use case for per-frame scalar data: send all these packets in the > > vector to a certain ip address, where the ip address could be stored in 4 > > or 16 octets’ worth of scalar data. > > > > > > > > HTH... Dave > > > > > > > > -----Original Message----- > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Raj > > Sent: Thursday, January 31, 2019 9:27 AM > > To: vpp-dev <vpp-dev@lists.fd.io> > > Subject: [vpp-dev] Understanding vlib_frame_t > > > > > > > > Hello all, > > > > > > > > Continuing my reading of VPP code, I have a query regarding packet handling. > > > > > > > > When a node gets a vector of packets to process, if I understand correctly, > > this would be a vlib_frame_t instance. From this vlib_frame_t instance > > arguments[0] is the offset to first packet, arguments[1] is the offset to > > second packet and so on, upto xx number of packets. Is this understanding > > correct? if yes, how much is the maximum size of the packet buffer? > > > > > > > > Also what is the significance of scalar_size/vector_size in vlib_frame_t? > > Does it mean the number of frames/size of frames? > > > > > > > > in vlib/main.c there is a statement vec_resize (nm->pending_frames, 32). > > In here, what is pending_frames and what is the significance of number 32? > > > > > > > > I know I have been asking too many questions over here and very grateful to > > all who answer. > > > > > > > > Thanks a lot! > > > > > > > > Raj
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12157): https://lists.fd.io/g/vpp-dev/message/12157 Mute This Topic: https://lists.fd.io/mt/29606187/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
