DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] mbuf: how to set data to NULL?
@ 2014-12-17 16:44 Kavanagh, Mark B
  2014-12-17 16:49 ` Bruce Richardson
  0 siblings, 1 reply; 5+ messages in thread
From: Kavanagh, Mark B @ 2014-12-17 16:44 UTC (permalink / raw)
  To: dev

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] mbuf: how to set data to NULL?
  2014-12-17 16:44 [dpdk-dev] mbuf: how to set data to NULL? Kavanagh, Mark B
@ 2014-12-17 16:49 ` Bruce Richardson
  2015-02-09 10:51   ` Kavanagh, Mark B
  0 siblings, 1 reply; 5+ messages in thread
From: Bruce Richardson @ 2014-12-17 16:49 UTC (permalink / raw)
  To: Kavanagh, Mark B; +Cc: dev

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?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] mbuf: how to set data to NULL?
  2014-12-17 16:49 ` Bruce Richardson
@ 2015-02-09 10:51   ` Kavanagh, Mark B
  2015-02-09 12:58     ` Bruce Richardson
  0 siblings, 1 reply; 5+ messages in thread
From: Kavanagh, Mark B @ 2015-02-09 10:51 UTC (permalink / raw)
  To: Richardson, Bruce; +Cc: dev

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@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?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] mbuf: how to set data to NULL?
  2015-02-09 10:51   ` Kavanagh, Mark B
@ 2015-02-09 12:58     ` Bruce Richardson
  2015-02-09 13:43       ` Kavanagh, Mark B
  0 siblings, 1 reply; 5+ messages in thread
From: Bruce Richardson @ 2015-02-09 12:58 UTC (permalink / raw)
  To: Kavanagh, Mark B; +Cc: dev

On Mon, Feb 09, 2015 at 10:51:36AM +0000, Kavanagh, Mark B wrote:
> 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
> 

I don't think there is any way to replicate this behaviour exactly with the new mbuf
structure. Memsetting zero may do what you want, but depending upon what the
meaning of an mbuf with NULL data is there may still be better ways to indicate
such a thing e.g. a flag value in another field, or setting data_len to -1?

/Bruce

> 
> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Wednesday, December 17, 2014 4:50 PM
> > To: Kavanagh, Mark B
> > Cc: dev@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?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [dpdk-dev] mbuf: how to set data to NULL?
  2015-02-09 12:58     ` Bruce Richardson
@ 2015-02-09 13:43       ` Kavanagh, Mark B
  0 siblings, 0 replies; 5+ messages in thread
From: Kavanagh, Mark B @ 2015-02-09 13:43 UTC (permalink / raw)
  To: Richardson, Bruce; +Cc: dev

Hi Bruce,

I figured as much, thanks for confirming.

We'll probably go with a flag.

Thanks again,
Mark

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday, February 9, 2015 12:59 PM
> To: Kavanagh, Mark B
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] mbuf: how to set data to NULL?
> 
> On Mon, Feb 09, 2015 at 10:51:36AM +0000, Kavanagh, Mark B wrote:
> > 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
> >
> 
> I don't think there is any way to replicate this behaviour exactly with the new mbuf
> structure. Memsetting zero may do what you want, but depending upon what the
> meaning of an mbuf with NULL data is there may still be better ways to indicate
> such a thing e.g. a flag value in another field, or setting data_len to -1?
> 
> /Bruce
> 
> >
> > > -----Original Message-----
> > > From: Richardson, Bruce
> > > Sent: Wednesday, December 17, 2014 4:50 PM
> > > To: Kavanagh, Mark B
> > > Cc: dev@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?

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-02-09 13:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-17 16:44 [dpdk-dev] mbuf: how to set data to NULL? Kavanagh, Mark B
2014-12-17 16:49 ` Bruce Richardson
2015-02-09 10:51   ` Kavanagh, Mark B
2015-02-09 12:58     ` Bruce Richardson
2015-02-09 13:43       ` Kavanagh, Mark B

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).