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 17FB25A71 for ; Mon, 12 Jan 2015 04:41:46 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 11 Jan 2015 19:36:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="439308008" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by FMSMGA003.fm.intel.com with ESMTP; 11 Jan 2015 19:29:00 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 12 Jan 2015 11:41:44 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.92]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 11:41:42 +0800 From: "Liu, Jijiang" To: Olivier MATZ , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine Thread-Index: AQHQFSv0txinLaq/UEmWgzF3v0CZupyLMv5ggABvM4CAJx3DUIABUNAAgACeQOD//4WHgIAB0/cg//+qC4CAAY+2AIAEp+6Q Date: Mon, 12 Jan 2015 03:41:42 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> References: <1418173403-30202-1-git-send-email-jijiang.liu@intel.com> <54896F4A.4070601@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA1B70@SHSMSX101.ccr.corp.intel.com> <548B18C9.3020408@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA7699@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D337B@irsmsx105.ger.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA789E@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D34AE@irsmsx105.ger.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA7CC5@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D3897@irsmsx105.ger.corp.intel.com> <54AFB13E.2080200@6wind.com> In-Reply-To: <54AFB13E.2080200@6wind.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 v3 0/3] enhance TX checksum command and csum forwarding engine 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, 12 Jan 2015 03:41:47 -0000 Hi, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Friday, January 9, 2015 6:45 PM > To: Ananyev, Konstantin; Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and > csum forwarding engine >=20 > Hi, >=20 > Thank you Jijiang for taking the time to get back on this. >=20 > On 01/08/2015 11:54 AM, Ananyev, Konstantin wrote: > >> And we are able to test all of cases in > >> http://dpdk.org/ml/archives/dev/2014-December/009213.html > >> > >> Test case A: > >> > >> tx_checksum set sw-tunnel-mode off > >> tx_checksum set hw-tunnel-mode off > >> tx_checksum set ip hw > >> > >> test case B.1: > >> > >> tx_checksum set sw-tunnel-mode on > >> tx_checksum set hw-tunnel-mode on > >> tx_checksum set ip hw > >> tx_checksum set tcp hw > >> > >> test case B.2: > >> > >> tx_checksum set sw-tunnel-mode on > >> tx_checksum set hw-tunnel-mode off > >> tx_checksum set ip hw > >> > >> test case C: > >> > >> tx_checksum set sw-tunnel-mode on > >> tx_checksum set hw-tunnel-mode on > >> tx_checksum set outer-ip hw > >> tx_checksum set ip hw > >> tx_checksum set tcp hw >=20 > There is something I don't understand. A forward engine takes any packet = in input > and output. Packets can be of any kind (eth/arp, eth/ip/tcp, > eth/vlan/ip/udp/vxlan/eth/ip/tcp, ...) Yes. > Today, the behavior of csum forward engine is defined for any kind of pac= ket. See > the description and the table in http://dpdk.org/ml/archives/dev/2014- > December/009886.html >=20 > All packets that are not "Ether[/vlan]/(IP|IP6)/(UDP|TCP|SCTP)" or > "Ether[/vlan]/(IP|IP6)/UDP/VxLAN/Ether[/vlan]/(IP|IP6)/UDP|TCP|SCTP" > are forwarded without beeing modified. Yes > In my understanding, the use-case you are describing correspond to specif= ic > packet types. So a configuration would work only for one packet format on= ly. Is it > correct? The use-cases I described correspond to all tunneling packet type, not just= for "Ether[/vlan]/(IP|IP6)/UDP/VxLAN/Ether[/vlan]/(IP|IP6)/UDP|TCP|SCTP" = packet format. Our goal is to have TX checksum framework that can cover all the case in th= e http://dpdk.org/ml/archives/dev/2014-December/009213.html and all packet= types in csum fwd engine. If so, it is easy to support other tunneling type in csum fwd engine in the= future.=20 There are some examples for the different packet types: 1. For L2 Packet types: MAC, ARP MAC, PAY2 ... They are forwarded without beeing modified no matter if these above command= s are set. 2. For Non Tunneled IPv4/6 packet MAC, IPV4, UDP, PAY4 MAC, IPV6, UDP, PAY4 ... Ipv4: tx_checksum set ip hw tx_checksum set udp hw IPv6: tx_checksum set udp hw They are forwarded with TX checksum offload if these above commands are set= . 3. For Tunneled IPv4/6 packet See the above test cases: Test case A test case B.1 test case B.2 test case C They are forwarded with TX checksum offload if these above commands are set= . > I think that the test-pmd command API should define a behavior for the cs= um > forward engine for any packet. What do you think? Agree. Let me explain the checksum offload behavior of different packet type below= , 1. For L2 Packet types: Checksum offload behavior definition: tx_checksum set sw-tunnel-mode on : NONE tx_checksum set hw-tunnel-mode on: NONE tx_checksum set outer-ip|ip|tcp|udp|sctp hw: NONE 2. For Non Tunneled IPv4/6 packet Checksum offload behavior definition: tx_checksum set sw-tunnel-mode on : NONE tx_checksum set hw-tunnel-mode on: NONE =20 tx_checksum set outer-ip|ip|tcp|udp|sctp hw: ip|tcp|udp|sctp options= are VALID 3. For Tunneled IPv4/6 packet Checksum offload behavior definition: tx_checksum set sw-tunnel-mode on : VALID tx_checksum set hw-tunnel-mode on: VALID=20 tx_checksum set outer-ip|ip|tcp|udp|sctp hw: VALID It is very welcome if you have better solution that is able to cover all th= e case in the http://dpdk.org/ml/archives/dev/2014-December/009213.html an= d all packet types in csum fwd engine. >=20 > Regards, > Olivier