From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 1F5615677 for ; Mon, 15 Feb 2016 14:15:54 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 15 Feb 2016 05:15:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,450,1449561600"; d="scan'208";a="902926152" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga001.fm.intel.com with ESMTP; 15 Feb 2016 05:15:53 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 15 Feb 2016 13:15:52 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.237]) by IRSMSX156.ger.corp.intel.com ([10.108.20.68]) with mapi id 14.03.0248.002; Mon, 15 Feb 2016 13:15:52 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , "Lu, Wenzhuo" Thread-Topic: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load Thread-Index: AQHRTmx6pDjluNdEOkuM1xLphszVbZ8cWdZwgBBt24CAAEuwgIAAF5sg Date: Mon, 15 Feb 2016 13:15:51 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B06CA7@irsmsx105.ger.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> In-Reply-To: <1958817.fmrgW3e0Zp@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTZhOGQ5OTktYTI3NS00Yjg0LWE1OTktMTQwZTA5NzI5OTcyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp3ZEs0b0h5cTdNNUNPQlJENHN1SWllMUhCQWJVZ3lKYXp2UFdOUTV6UE09In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] 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: Mon, 15 Feb 2016 13:15:55 -0000 Hi lads, > -----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 ch= ecksum off-load >=20 > 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 that flag for now a= t all? > > The reason is we need to set the tunnel type in the Advanced Transmit D= ata Descriptor. Yes, I saw that in x550 spec, though I really doubt it is needed to calcula= te 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 are = sent from one VF to another.=20 In that case, HW probably would try to avoid extra packet scanning and rely= on information from SW. As mentioned in x550 spec, section's note: "...In virtualization mode, packets might be received from other local VMs.= The X550 does not check the L5 header for these packets and does not report NFS header. If su= ch packets carry IP tunneling (IPv4 - IPv6), they are reported as IPV4E. The packets receive= d from local VM are indicated by the LB bit in the status field. To be identified, the CC b= it in the transmit descriptor must be set and if it is a tunnel packet, the TUNNEL.OUTERIPCS m= ust 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 Type'= field at all. >=20 > Why don't we use packet type? Yes, that's probably another possible way, if we really decide to setup thi= s info at TX descriptor. BTW, reading x550 spec, I think ixgbe RX code that setups packet_type need = to be updated too. Right now it can't handle vxlan/gre tunnelling case. Konstantin >=20 > > > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM (a= s 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. >=20 > Yes there can be a lot of tunnel types. > Please check RTE_PTYPE_TUNNEL_* >=20