From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id D54B45955 for ; Mon, 7 Sep 2015 13:23:08 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 07 Sep 2015 04:23:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,484,1437462000"; d="scan'208";a="764023944" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga001.jf.intel.com with ESMTP; 07 Sep 2015 04:23:07 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 7 Sep 2015 12:23:06 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.51]) by irsmsx111.ger.corp.intel.com ([169.254.2.19]) with mapi id 14.03.0224.002; Mon, 7 Sep 2015 12:23:06 +0100 From: "Ananyev, Konstantin" To: "Dumitrescu, Cristian" , "Azarewicz, PiotrX T" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment extension header Thread-Index: AQHQ6V9ZG2Mm1jJj+0avNCxzqy6BJ54w7Brw Date: Mon, 7 Sep 2015 11:23:05 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836A83DF0@irsmsx105.ger.corp.intel.com> References: <1441203181-15487-1-git-send-email-piotrx.t.azarewicz@intel.com> <2601191342CEEE43887BDE71AB97725836A83591@irsmsx105.ger.corp.intel.com> <3EB4FA525960D640B5BDFFD6A3D89126478B81C4@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D89126478B81C4@IRSMSX108.ger.corp.intel.com> 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 Subject: Re: [dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment extension header 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, 07 Sep 2015 11:23:09 -0000 > -----Original Message----- > From: Dumitrescu, Cristian > Sent: Monday, September 07, 2015 12:22 PM > To: Ananyev, Konstantin; Azarewicz, PiotrX T; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment e= xtension header >=20 >=20 >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, > > Konstantin > > Sent: Friday, September 4, 2015 6:51 PM > > To: Azarewicz, PiotrX T; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment > > extension header > > > > Hi Piotr, > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Piotr > > > Sent: Wednesday, September 02, 2015 3:13 PM > > > To: dev@dpdk.org > > > Subject: [dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment > > extension header > > > > > > From: Piotr Azarewicz > > > > > > Previous implementation won't work on every environment. The order of > > > allocation of bit-fields within a unit (high-order to low-order or > > > low-order to high-order) is implementation-defined. > > > Solution: used bytes instead of bit fields. > > > > Seems like right thing to do to me. > > Though I think we also should replace: > > union { > > struct { > > uint16_t frag_offset:13; /**< Offset from the s= tart of the packet > > */ > > uint16_t reserved2:2; /**< Reserved */ > > uint16_t more_frags:1; > > /**< 1 if more fragments left, 0 if last fragme= nt */ > > }; > > uint16_t frag_data; > > /**< union of all fragmentation data */ > > }; > > > > With just: > > uint16_t frag_data; > > and probably provide macros to read/set fragment_offset and more_flags > > values. > > Otherwise people might keep using the wrong layout. > > Konstantin > > >=20 > I agree with your proposal, but wouldn't this be an ABI change? To avoid = an ABI change, we should probably leave the union? No I don't think it would - the size of the field will remain the same: uin= t16_t. Also if the bit-field is invalid what for to keep it? Konstantin >=20 > > > > > > Signed-off-by: Piotr Azarewicz > > > --- > > > lib/librte_ip_frag/rte_ipv6_fragmentation.c | 6 ++---- > > > 1 file changed, 2 insertions(+), 4 deletions(-) > > > > > > diff --git a/lib/librte_ip_frag/rte_ipv6_fragmentation.c > > b/lib/librte_ip_frag/rte_ipv6_fragmentation.c > > > index 0e32aa8..7342421 100644 > > > --- a/lib/librte_ip_frag/rte_ipv6_fragmentation.c > > > +++ b/lib/librte_ip_frag/rte_ipv6_fragmentation.c > > > @@ -65,10 +65,8 @@ __fill_ipv6hdr_frag(struct ipv6_hdr *dst, > > > > > > fh =3D (struct ipv6_extension_fragment *) ++dst; > > > fh->next_header =3D src->proto; > > > - fh->reserved1 =3D 0; > > > - fh->frag_offset =3D rte_cpu_to_be_16(fofs); > > > - fh->reserved2 =3D 0; > > > - fh->more_frags =3D rte_cpu_to_be_16(mf); > > > + fh->reserved1 =3D 0; > > > + fh->frag_data =3D rte_cpu_to_be_16((fofs & ~IPV6_HDR_FO_MASK) | > > mf); > > > fh->id =3D 0; > > > } > > > > > > -- > > > 1.7.9.5