...and I must quickly add that I do recognize that the field is lying inside a union where the next bigger member of the union is 16 bytes long. So I will be careful to skip the first 16 bytes of the u32 unused[10]; and claim the rest of the real estate as my own.
Please do let me know if I am about to shoot at my own foot. On Fri, Sep 21, 2018 at 9:58 PM Prashant Upadhyaya <praupadhy...@gmail.com> wrote: > > Thanks Dave, Damjan for the shove in the right direction ! > I believe that the safest field to use is vnet_buffer_opaque2_t-> u32 > unused[10] > So far as I confine myself to the above, I should be able to use it > the way I want without affecting anything else. > If the above is a naive understanding, please do educate me further on this. > > Regards > -Prashant > > On Fri, Sep 21, 2018 at 5:32 PM Dave Barach (dbarach) <dbar...@cisco.com> > wrote: > > > > +1. Note the vnet_buffer(b) and vnet_buffer2(b) macros. Track down the > > definitions in .../src/vlib/buffer.h and .../src/vnet/buffer.h and you’ll > > understand how these opaque buffer metadata spaces are to be used. > > > > > > > > Depending on where your graph nodes land, you must be careful not to smash > > metadata which will be used downstream. > > > > > > > > Due to load-store unit pressure, (especially) vnet_buffer(b) fields are > > overlaid and have multiple uses. Any new use-case needs careful [manual] > > life-cycle analysis. > > > > > > > > Example: if you set vnet_buffer(b)->sw_if_index[VLIB_TX] to a random number > > and ship that buffer to ip4/6-lookup, you’ll get a nasty surprise. > > > > > > > > D. > > > > > > > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Damjan Marion > > via Lists.Fd.Io > > Sent: Friday, September 21, 2018 6:36 AM > > To: Prashant Upadhyaya <praupadhy...@gmail.com> > > Cc: vpp-dev@lists.fd.io > > Subject: Re: [vpp-dev] Regarding pre_data field in vlib_buffer_t > > > > > > > > > > > > pre_data is not intended for that. It is headroom space which may be used > > > > for outer headers in case of different tunnel encapsulation. > > > > > > > > You can use opaque area in vlib_buffer_t.... > > > > > > > > -- > > Damjan > > > > > > > > On 21 Sep 2018, at 07:59, Prashant Upadhyaya <praupadhy...@gmail.com> wrote: > > > > > > > > Hi, > > > > I want to pass around some custom data between my plugins using > > vlib_buffer_t. > > I believe the pre_data field of 128 bytes can be used for this. (I use > > the DPDK plugin) > > > > However, are there some best practices to use this field ? I ask this > > because I do see that some debug capabilities of VPP use this field > > and if I start using this field then it might interfere with those > > debug capabilties. > > > > Regards > > -Prashant > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > > > View/Reply Online (#10594): https://lists.fd.io/g/vpp-dev/message/10594 > > Mute This Topic: https://lists.fd.io/mt/25840898/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 (#10601): https://lists.fd.io/g/vpp-dev/message/10601 Mute This Topic: https://lists.fd.io/mt/25840898/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
