From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id EEA282C7A for ; Mon, 9 Feb 2015 14:43:57 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 09 Feb 2015 05:36:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,544,1418112000"; d="scan'208";a="649483351" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga001.jf.intel.com with ESMTP; 09 Feb 2015 05:43:56 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.81]) by IRSMSX103.ger.corp.intel.com ([169.254.3.242]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 13:43:54 +0000 From: "Kavanagh, Mark B" To: "Richardson, Bruce" Thread-Topic: [dpdk-dev] mbuf: how to set data to NULL? Thread-Index: AdAaGLFf9AHMOhYQSC+f0gYZzu+G5AAAL6qACo7Ci2AABOkuAAAAzmDg Date: Mon, 9 Feb 2015 13:43:53 +0000 Message-ID: References: <20141217164934.GA6980@bricha3-MOBL3> <20150209125838.GA17180@bricha3-MOBL3> In-Reply-To: <20150209125838.GA17180@bricha3-MOBL3> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] mbuf: how to set data to NULL? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:43:58 -0000 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? >=20 > 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 getti= ng at is trying > to understand the implications of removing the data pointer, and determin= e 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: > > =3D> buf.data =3D NULL; > > Then, when I subsequently attempt to access the mbuf' data sectio= n, > rte_pktmbuf_mtod(buf) returns NULL > > > > DPDK 1.8: I want to set an mbuf's data to NULL: > > =3D> buf.data_off =3D 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 dat= a value of NULL. > > > > Thanks, > > Mark > > >=20 > I don't think there is any way to replicate this behaviour exactly with t= he 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 in= dicate > such a thing e.g. a flag value in another field, or setting data_len to -= 1? >=20 > /Bruce >=20 > > > > > -----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 t= hat the start of > the > > > data in the segment buffer must be calculated (i.e. buf_addr + data_o= ff =3D 'data'). > > > > > > > > Given this, what is the best approach to set the mbuf data to NULL = (previously > mbuf.data > > > =3D NULL)? > > > > > > > > As I see it, given an initialized mbuf, such that buf_addr is non-n= ull, and data_off > > > =3DRTE_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 =3D 0 to indicate an empty mbuf?