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 723F75A97 for ; Wed, 17 Feb 2016 06:47:11 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 16 Feb 2016 21:47:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,458,1449561600"; d="scan'208";a="653346168" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 16 Feb 2016 21:47:10 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 16 Feb 2016 21:47:09 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 16 Feb 2016 21:47:09 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.172]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.84]) with mapi id 14.03.0248.002; Wed, 17 Feb 2016 13:47:08 +0800 From: "Lu, Wenzhuo" To: "Ananyev, Konstantin" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load Thread-Index: AQHRX32U8uhWbDQ7Rku34RjjFnJfjJ8sdFhQ///2yoCAADXCgIADLL+w Date: Wed, 17 Feb 2016 05:47:08 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09090342B557@shsmsx102.ccr.corp.intel.com> References: <1452496044-17524-1-git-send-email-wenzhuo.lu@intel.com> <2601191342CEEE43887BDE71AB97725836B03304@irsmsx105.ger.corp.intel.com> <6A0DE07E22DDAD4C9103DF62FEBC09090342A92F@shsmsx102.ccr.corp.intel.com> <1958817.fmrgW3e0Zp@xps13> <2601191342CEEE43887BDE71AB97725836B06CA7@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836B06CA7@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 v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load 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: Wed, 17 Feb 2016 05:47:12 -0000 Hi Konstantin, > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, February 15, 2016 9:16 PM > To: Thomas Monjalon; Lu, Wenzhuo > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX > checksum off-load >=20 > Hi lads, >=20 > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Monday, February 15, 2016 10:03 AM > > To: Lu, Wenzhuo > > Cc: dev@dpdk.org; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX > > checksum off-load > > > > 2016-02-15 05:32, Lu, Wenzhuo: > > > From: Ananyev, Konstantin > > > > From reading X550 spec, I don't really understand what for we need > > > > to specify is it GRE or VXLAN packet, so probably we don't need tha= t flag > for now at all? > > > The reason is we need to set the tunnel type in the Advanced Transmit= Data > Descriptor. >=20 > Yes, I saw that in x550 spec, though I really doubt it is needed to calcu= late etiher > outer IP, or inner IP/L4 checksum. > After all TUNNELLEN includes all tunnel headers plus inner L2 length. > The only reason I can think it might be useful for HW is when packets ar= e sent > from one VF to another. > In that case, HW probably would try to avoid extra packet scanning and re= ly on > information from SW. > As mentioned in x550 spec, section's note: > "...In virtualization mode, packets might be received from other local VM= s. The > X550 does not check the L5 header for these packets and does not report N= FS > header. If such packets carry IP tunneling (IPv4 - IPv6), they are report= ed as > IPV4E. The packets received from local VM are indicated by the LB bit in = the > status field. To be identified, the CC bit in the transmit descriptor mus= t be set > and if it is a tunnel packet, the TUNNEL.OUTERIPCS must be set also." > Though I am not sure we do need to support that case. > That's why probably the easiest way would be to avoid setting 'Tunnel Typ= e' field > at all. Many thanks for your suggestion. I think you're right. For outer IP header checksum offload, we need not to set the tunnel type bi= t. I'll choose this option and remove this vxlan ol_flag. >=20 > > > > Why don't we use packet type? >=20 > Yes, that's probably another possible way, if we really decide to setup t= his info > at TX descriptor. >=20 > BTW, reading x550 spec, I think ixgbe RX code that setups packet_type nee= d to > be updated too. > Right now it can't handle vxlan/gre tunnelling case. >=20 > Konstantin >=20 > > > > > > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM > > > > (as enum) and reserve few values for future expansion (2 or 3 bits?= ). > > > Now there're only VxLAN and NVGRE supported. So, only 1 bit is > > > occupied for that. Not sure if more types will be supported in the > > future. Any suggestions? Thanks. > > > > Yes there can be a lot of tunnel types. > > Please check RTE_PTYPE_TUNNEL_* > >