DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Kavanagh, Mark B" <mark.b.kavanagh@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] mbuf: how to set data to NULL?
Date: Mon, 9 Feb 2015 10:51:36 +0000	[thread overview]
Message-ID: <DC5AD7FA266D86499789B1BCAEC715F846D228C4@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <20141217164934.GA6980@bricha3-MOBL3>

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?

  reply	other threads:[~2015-02-09 10:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-17 16:44 Kavanagh, Mark B
2014-12-17 16:49 ` Bruce Richardson
2015-02-09 10:51   ` Kavanagh, Mark B [this message]
2015-02-09 12:58     ` Bruce Richardson
2015-02-09 13:43       ` Kavanagh, Mark B

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DC5AD7FA266D86499789B1BCAEC715F846D228C4@irsmsx105.ger.corp.intel.com \
    --to=mark.b.kavanagh@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).