Hi Bruce,
As a follow-on to my previous question: I suppose what I'm really getting at is
trying to understand the implications of removing the data pointer, and
determine if it's possible to replicate behavior observed in DPDK 1.7 (which we
need in our use case).
Take this situation for example:
DPDK 1.7: I want to set an mbuf's data to NULL:
=> buf.data = NULL;
Then, when I subsequently attempt to access the mbuf' data
section, rte_pktmbuf_mtod(buf) returns NULL
DPDK 1.8: I want to set an mbuf's data to NULL:
=> buf.data_off = 0; (is this correct?)
Then, if I attempt to access the mbuf's data, instead of NULL,
rte_pktmbuf_mtod(buf) returns buf_addr, not NULL.
Is it possible in DPDK 1.8 to replicate the same behavior observed in 1.7?
Btw, in our use case a data_len of 0 doesn't necessarily indicate a data value
of NULL.
Thanks,
Mark
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Wednesday, December 17, 2014 4:50 PM
> To: Kavanagh, Mark B
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] mbuf: how to set data to NULL?
>
> On Wed, Dec 17, 2014 at 04:44:15PM +0000, Kavanagh, Mark B wrote:
> > Hi,
> >
> > DPDK 1.8.0 removes the data pointer from the mbuf structure, such that the
> > start of the
> data in the segment buffer must be calculated (i.e. buf_addr + data_off =
> 'data').
> >
> > Given this, what is the best approach to set the mbuf data to NULL
> > (previously mbuf.data
> = NULL)?
> >
> > As I see it, given an initialized mbuf, such that buf_addr is non-null, and
> > data_off
> =RTE_PKTMBUF_HEADROOM, is it fair to say that the best solution is to memset
> to 0 from
> location (buf_addr + data_off) for a length of (data_len - data_off)?
> >
> > Thanks in advance,
> > Mark
>
> Why not just set data_len = 0 to indicate an empty mbuf?
