> On 26 Mar 2019, at 17:45, G. Paul Ziemba <pz-vpp-...@ziemba.us> wrote: > > I'm still new to VPP, so I thank you more experienced folks for > your insights. I'm implementing a tunneling protocol which requires > fragmentation and aggregation of packets. > > In a traditional system with mbufs (or dpdk buffers), it is > possible to make a new buffer metadata chain referencing > a piece of the original packet without copying the packet data. > One key part of this is that the new chain can reference > arbitrary chunks of data from N original packets, and that > multiple such new chains can do so independently over a given > original packet.
We do that by cloning, you can have multiple head buffers with small amount if data to accommodate l2/l3 headers and then such buffers have b->next_buffer pointing to shared tail buffer(s). Tail buffer(s) just need to have ref_count set properly to avoid that such buffer is freed prematurely. > > Maybe I have misunderstood the way vlib buffers work, but it seems > this approach is not possible here. For example the IP fragmentation > code in vnet/ip/ip_frag.c copies the packet data, as does > vlib_buffer_clone(). > > While avoiding a pointer lookup per packet is a win in the normal case, > it seems pessimal for fragmentation/deaggregation. Yes, and we care much more about normal cases than for fragmentation. People should avoid fragmentation / reassembly. It is evil. > > My initial thought is to support indirect data by adding, to the vlib > buffer metadata, a flag bit and a buffer index for indirect data, as > well as some kind of offset and length values. These could probably fit > in the existing user flag and opaque areas. That will cost roughly one clock/packet in each node which does anything with the data. > > The other change would be something in the packet output code to > handle this format. Is it correct that the VPP interface output > functions eventually call dpdk interface transmit functions? I'm > guessing that would be the place to do it. > > Am I missing something? Is there a better way to approach this problem? > > thanks! > -- > G. Paul Ziemba > FreeBSD unix: > 9:46AM up 149 days, 18:50, 19 users, load averages: 0.22, 0.28, 0.29 > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#12641): https://lists.fd.io/g/vpp-dev/message/12641 > Mute This Topic: https://lists.fd.io/mt/30784477/675642 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12642): https://lists.fd.io/g/vpp-dev/message/12642 Mute This Topic: https://lists.fd.io/mt/30784477/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
