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 (#12128): https://lists.fd.io/g/vpp-dev/message/12128
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]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to