From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id EAEA45A89 for ; Mon, 12 Jan 2015 12:43:36 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YAdSZ-0007kT-Cv; Mon, 12 Jan 2015 12:47:07 +0100 Message-ID: <54B3B35A.5030803@6wind.com> Date: Mon, 12 Jan 2015 12:43:22 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: "Liu, Jijiang" , "Ananyev, Konstantin" 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> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 11:43:37 -0000 Hi Jijiang, Please find some comments below. 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. ok > 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. Two questions here: - today, we also have the "sw" argument that allows to calculate the checksum in software. Do you plan to keep this behavior? - 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? 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 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 > 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 the case in the http://dpdk.org/ml/archives/dev/2014-December/009213.html and all packet types in csum fwd engine. Thank you for your efforts to explain your proposition. I still have some difficulties to understand the naming "sw-tunnel" and "hw-tunnel". >>From the user point of view "sw" means "software" and "hw" means "hardware". I think it's difficult to understand how both can be on at the same time. Maybe it's just a naming problem? Also, is it still possible to compute the checksum in software? And will it be possible to support future hardware that will be able to compute both outer l3, outer l4, l3 and l4 checksums? I have another idea, please let me know if you find it clearer or not. The commands format would be: tx_checksum ... List of commands: # select behavior for non tunnel packets tx_checksum ip-udp l3 off|sw|hw l4 off|sw|hw tx_checksum ip-tcp l3 off|sw|hw l4 off|sw|hw tx_checksum ip-sctp l3 off|sw|hw l4 off|sw|hw tx_checksum ip-other l3 off|sw|hw # 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 tx_checksum vxlan-ip-tcp l3 off|sw|hw l4 off|sw|hw tx_checksum vxlan-ip-sctp l3 off|sw|hw l4 off|sw|hw tx_checksum vxlan-ip-other l3 off|sw|hw Examples: 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 # assume all is off by default tx_checksum ip-udp l3 hw l4 hw tx_checksum ip-tcp l3 sw l4 sw 2. calculate outer checksums of tunnel packets (your case A.) # assume all is off by default tx_checksum vxlan outer-l3 hw outer-l4 hw 3. calculate inner checksums of tunnel packets (your case B.1) # 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 4. calculate all checksums of tunnel packets (your case C) # 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 l4 hw Advantages: - clearer from use point of view: the user knows what is done for each packet type - software checksum is supported for comparison with hw - the syntax already supports future hw that can do outer l3, outer l4, l3 and l4 at the same time. - we can add future tunnel packets in the same model: tx_checksum gre outer-l3 off|sw|hw tx_checksum gre-ip-udp l3 off|sw|hw l4 off|sw|hw Cons: - with the definition above, we cannot do B.2. But if we really want it, we could change the commands: tx_checksum xxx l3 off|sw|hw|outer-hw l4 off|sw|hw|outer-hw "outer-hw" means: use the outer mbuf flags to do the checksum It could be replaced in all commands - this commands may lead to impossible configurations, but it can be checked by testpmd and a warning can be displayed. What do you think? Regards, Olivier