From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B12193F9 for ; Mon, 1 Dec 2014 03:30:50 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 30 Nov 2014 18:30:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,489,1413270000"; d="scan'208";a="616376493" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by orsmga001.jf.intel.com with ESMTP; 30 Nov 2014 18:30:48 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Dec 2014 10:30:41 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 10:30:40 +0800 From: "Liu, Jijiang" To: "Ananyev, Konstantin" , Olivier MATZ Thread-Topic: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields Thread-Index: AQHQCij3gT8zSau+ukaSqjkBc7C0OJx0gSYg//+JDYCAACL2gIABKWIAgANpAQCAAUd7UA== Date: Mon, 1 Dec 2014 02:30:40 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9F58E@SHSMSX101.ccr.corp.intel.com> References: <1417076319-629-1-git-send-email-jijiang.liu@intel.com> <1417076319-629-2-git-send-email-jijiang.liu@intel.com> <5476F626.2020708@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9EEA0@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213BADB8@IRSMSX105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258213BAE90@IRSMSX105.ger.corp.intel.com> <54785264.1020208@6wind.com> <2601191342CEEE43887BDE71AB977258213BB795@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BB795@IRSMSX105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and change three fields 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, 01 Dec 2014 02:30:51 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Sunday, November 30, 2014 10:51 PM > To: Olivier MATZ; Liu, Jijiang > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and cha= nge > three fields >=20 > Hi Olver, >=20 > > -----Original Message----- > > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > > Sent: Friday, November 28, 2014 10:46 AM > > To: Ananyev, Konstantin; Liu, Jijiang > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf:add two TX offload flags and > > change three fields > > > > Hi Konstantin, > > > > On 11/27/2014 06:01 PM, Ananyev, Konstantin wrote: > > >> Yes, I think it could be done that way too. > > >> Though I still prefer to keep l4tun_len - it makes things a bit clea= ner (at least > to me). > > >> After all we do have space for it in mbuf's tx_offload. > > > > > > As one more thing in favour of separate l4tun_len field: > > > l2_len is 7 bit long, so in theory it might be not enough, as for FVL= : > > > 12:18 L4TUNLEN L4 Tunneling Length (Teredo / GRE header / VXLAN heade= r) > defined in Words. > > > > The l2_len field is 7 bits long because it was mapped to ixgbe hardware= . > > If it's not enough (although I'm not sure it's possible to have a > > header larger than 128 bytes in this case), it's probably because we > > should not have been doing that. > > Maybe these generic fields should be generic :) If it's not enough, > > what about changing l2_len to 8 bits? > > > > Often in the recent discussions, I see as an argument "fortville needs > > this so we need to add it in the mbuf". I agree that currently > > fortville is the only hardware supported for the new features, so it > > can make sense to act like this, but we have to accept to come back to > > this API in the future if it makes less sense with other drivers. > > > > Also, application developers can be annoyed to see that the mbuf flags > > and meta data are just duplicating information that is already present > > in the packet. > > > > About the l4tun_len, it's another field the application has to fill, > > but it's maybe cleaner. I just wanted to clarify why I'm discussing > > these points. >=20 > After another thought, I think that the way you proposed is a better one. > I gives us more flexibility: > let's say for now we'll keep both l2_len and outer_l2_len as 7 bit fields= , and upper > layer would have to: > mb->l2_len =3D eth_hdr_in + vxlan_hdr; A question, how to fill the mb->l2_len for IP in IP, IP in GRE tunneling p= acket that is no inner L2 header? What is the rule? Or you think it should be mb->l2_len =3D 0 + l4_tun_len; ?? > for VXLAN packets. > Then if in the future, we'll realise that 7 bit is not enough we can eith= er: > - increase size of l2_len and outer_l2_len > - introduce new field (l4tun_len as we planned now) In both cases backwar= d > compatibility wouldn't be affected. > From other side - if we'' introduce a new field now (l4tun_len), it would= be very > hard to get rid of it in the future. > So, I think we'd better follow your approach here. >=20 > Thanks > Konstantin >=20 >=20 > > > > Regards, > > Olivier