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 91639282 for ; Tue, 13 Jan 2015 04:04:26 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 12 Jan 2015 19:04:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,691,1406617200"; d="scan'208";a="511307960" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by orsmga003.jf.intel.com with ESMTP; 12 Jan 2015 18:58:05 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 13 Jan 2015 11:04:10 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 11:04:09 +0800 From: "Liu, Jijiang" To: Olivier MATZ Thread-Topic: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine Thread-Index: AQHQFSv0txinLaq/UEmWgzF3v0CZupyLMv5ggABvM4CAJx3DUIABUNAAgACeQOD//4WHgIAB0/cg//+qC4CAAY+2AIAEp+6QgAAfSgCAAWHEQA== Date: Tue, 13 Jan 2015 03:04:08 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@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> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> <54B3B35A.5030803@6wind.com> In-Reply-To: <54B3B35A.5030803@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: Tue, 13 Jan 2015 03:04:27 -0000 Hi, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Monday, January 12, 2015 7:43 PM > To: Liu, Jijiang; Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and > csum forwarding engine >=20 > Hi Jijiang, >=20 > Please find some comments below. >=20 > On 01/12/2015 04:41 AM, Liu, Jijiang wrote: > > 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 > commands are set. >=20 > ok >=20 > > 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. >=20 > Two questions here: >=20 > - today, we also have the "sw" argument that allows to calculate the > checksum in software. Do you plan to keep this behavior? Yes > - today, the csumonly forward engine modifies the IP addresses to > validate that it is able to recalculate the checksum. Do you plan > to keep this behavior?=20 Yes > I'm not opposed to remove it if it makes > the code more complex. > > 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 csum 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 > > tx_checksum set outer-ip|ip|tcp|udp|sctp hw: ip|tcp|udp|sctp opt= ions > 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 > > 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 al= l the case in > the http://dpdk.org/ml/archives/dev/2014-December/009213.html and all > packet types in csum fwd engine. >=20 > Thank you for your efforts to explain your proposition. I still have some= difficulties > to understand the naming "sw-tunnel" and "hw-tunnel". Again, I'd like to explain what behaviors the following two commands are. 1. tx_checksum set sw-tunnel-mode on/off 2. tx_checksum set hw-tunnel-mode on/off For command 1, If the sw-tunnel-mode is set/clear, which will set/clear a t= estpmd flag that is used in the process of analyzing incoming packet., the = pseudo-codes are list below, If (sw-tunnel-mode)=20 Csum fwd engine will analyze if incoming packet is a tunneling packet. tunnel =3D 1; else Csum fwd engine will not analyze if incoming packet is a tunneli= ng packet, and treat all the incoming packets as non-tunneling packets.=20 It is used for A. For command 2, If the hw-tunnel-mode is set/clear, which will set/clear a t= estpmd flag that is used in the process of how to handle tunneling packet, = the pseudo-codes are list below, if (tunnel =3D=3D 1) { // this is a tunneling packet If (hw-tunnel-mode)=20 ol_flags |=3D PKT_TX_UDP_TUNNEL_PKT; Csum fwd engine set PKT_TX_UDP_TUNNEL_PKT offload flag, which means= to tell HW treat the transmit packet as a tunneling packet to do checksum= offload. It is used for B.1 Else Csum fwd engine doesn't set PKT_TX_UDP_TUNNEL_PKT of= fload flag, which means tell HW to treat the packet as ordinary (non-tunne= lled) packet. It is used for B.2 } > From the user point of view "sw" means "software" and "hw" means "hardwar= e". > I think it's difficult to understand how both can be on at the same time.= Maybe it's > just a naming problem? > Yes. Your comments make sense. And I think it's just a naming problem, I will co= mbine the two hw/sw-tunnel-mode commands into a command in order to make it= as simple and understandable as possible. tx_checksum set tunnel-mode (hw|none) when user set 'hw' option, the TESTPMD_TX_OFFLOAD_TUNNEL_CKSUM flag will = be set in cmdline; actually, the PKT_TX_UDP_TUNNEL_PKT offload flag will be= set if the testpmd flag is set, which tell driver/HW treat that transmi= t packet as a tunneling packet. When user set 'none' option, which means software and hardware will treat t= hat packet as ordinary packet(non-tunneling). List of commands for those cases. Test case A: tx_checksum set tunnel-mode none tx_checksum set ip hw test case B.1: tx_checksum set tunnel-mode hw tx_checksum set ip hw tx_checksum set tcp hw test case B.2: tx_checksum set ip hw test case C: tx_checksum set tunnel-mode hw tx_checksum set outer-ip hw tx_checksum set ip hw tx_checksum set tcp hw > Also, is it still possible to compute the checksum in software? Yes > And will it be possible to support future hardware that will be able to c= ompute > both outer l3, outer l4, l3 and l4 checksums? Yes.=20 Currently, i40e support outer l3, outer l4, l3 and l4 checksums offload at = the same time. test case C: tx_checksum set tunnel-mode hw tx_checksum set outer-ip hw tx_checksum set ip hw tx_checksum set tcp hw Of course, outer udp is not listed here for VXLAN. >=20 > I have another idea, please let me know if you find it clearer or not. > The commands format would be: >=20 > tx_checksum ... >=20 > List of commands: >=20 > # select behavior for non tunnel packets > tx_checksum ip-udp l3 off|sw|hw l4 off|sw|hw=20 > tx_checksum ip-tcp l3 off|sw|hw l4 off|sw|hw=20 > tx_checksum ip-sctp l off|sw|hw l4 off|sw|hw > tx_checksum ip-other l3 off|sw|hw >=20 > # select behavior for vxlan packets > tx_checksum vxlan outer-l3 off|sw|hw outer-l4 off|sw|hw > tx_checksum vxlan- ip-udp l3 off|sw|hw l4 off|sw|hw=20 > tx_checksum vxlan-ip-tcp l3 off|sw|hw l4off|sw|hw=20 >tx_checksum vxlan-ip-sctp l3 off|sw|hw l4 off|sw|hw=20 > tx_checksum vxlan-ip-other l3 off|sw|hw >=20 > Examples: >=20 > 1. calculate l3 and l4 checksum of ip/udp packets in hw, and ip/tcp > packets in sw. Do nothing for the other packet types >=20 > # assume all is off by default > tx_checksum ip-udp l3 hw l4 hw > tx_checksum ip-tcp l3 sw l4 sw >=20 > 2. calculate outer checksums of tunnel packets (your case A.) >=20 > # assume all is off by default > tx_checksum vxlan outer-l3 hw outer-l4 hw >=20 > 3. calculate inner checksums of tunnel packets (your case B.1) >=20 > # assume all is off by default > tx_checksum vxlan-ip-udp l3 hw l4 hw > tx_checksum vxlan-ip-tcp l3 hw l4 hw > tx_checksum vxlan-ip-sctp l3 hw l4 hw >=20 > 4. calculate all checksums of tunnel packets (your case C) >=20 > # assume all is off by default > tx_checksum vxlan outer-l3 hw outer-l4 hw tx_checksum vxlan-ip-udp l3 hw = l4 > hw tx_checksum vxlan-ip-tcp l3 hw l4 hw tx_checksum vxlan-ip-sctp l3 hw l= 4 hw >=20 >=20 > Advantages: >=20 > - clearer from use point of view: the user knows what is done for > each packet type >=20 > - software checksum is supported for comparison with hw >=20 > - the syntax already supports future hw that can do outer l3, outer l4, > l3 and l4 at the same time. >=20 > - we can add future tunnel packets in the same model: >=20 > tx_checksum gre outer-l3 off|sw|hw > tx_checksum gre-ip-udp l3 off|sw|hw l4 off|sw|hw >=20 > Cons: >=20 > - with the definition above, we cannot do B.2. But if we really want > it, we could change the commands: >=20 > tx_checksum xxx l3 off|sw|hw|outer-hw l4 off|sw|hw|outer-hw >=20 > "outer-hw" means: use the outer mbuf flags to do the checksum > It could be replaced in all commands >=20 > - this commands may lead to impossible configurations, but it can be > checked by testpmd and a warning can be displayed. >=20 >=20 > What do you think? Thanks for your proposal. It is clear for me. But there are two questions for me. As I know, in current command line framework, the option in command line is= exact match, so you probably have to add duplicated codes when you want to= support a new packet types. Other question: Currently, the following testpmd flag is for per port, not for per packet t= ype, when they are set, which will affect whole port, not just for packet t= ype or format, if you add option in cmdline, which means you h= ave to other changes. /** Offload IP checksum in csum forward engine */ #define TESTPMD_TX_OFFLOAD_IP_CKSUM 0x0001 /** Offload UDP checksum in csum forward engine */ #define TESTPMD_TX_OFFLOAD_UDP_CKSUM 0x0002 /** Offload TCP checksum in csum forward engine */ #define TESTPMD_TX_OFFLOAD_TCP_CKSUM 0x0004 /** Offload SCTP checksum in csum forward engine */ #define TESTPMD_TX_OFFLOAD_SCTP_CKSUM 0x0008 /** Offload VxLAN checksum in csum forward engine */ #define TESTPMD_TX_OFFLOAD_VXLAN_CKSUM 0x0010 Of course, it is welcome if you can send this patch set with this idea for = community review. > Regards, > Olivier