From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by dpdk.org (Postfix) with ESMTP id B57B85A7A for ; Tue, 13 Jan 2015 10:55:31 +0100 (CET) Received: by mail-we0-f181.google.com with SMTP id q58so1822918wes.12 for ; Tue, 13 Jan 2015 01:55:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h8EDjAcWrdigK3xoWAXb2JJ2PoxHxruwCTYv5zp3nEg=; b=Jl085VbrI84/DqxyHZMd4XIvAVcwpd8S0gHd8NNfwNtB6lj6qNxd/J04fwyHjBO4el dXB47Z4K8J/RS39UPashe2PJ/KNjza+nilMeA9BREXDKWh9rjwsPgpogngac1gsoAe6z 0x7abdzCIjOB+s7z3G2fP9JUceHLq4N/fpgor+iDEJNVh8lGRdozZ21If8q4XZZF/0KV xeq+fZ8J9iGEWS+gz3wZwsetpTja7ksKZj1FaT+LpUFXPs+n9rPsdDa0CoshkRoPOKN3 fgMkWY4+zI000k74haSQLbWFAOmdbPbWYauqmzB+zUNrQiZiTqwYAh7cRCSHa4Q/6Wwd 3idQ== X-Gm-Message-State: ALoCoQmmaIFWHbNiITvxFfFZibZNruBS/8c7lggCmP25jf8FlP4kE1baoeZl47ritVYMGh3LKV6H X-Received: by 10.194.90.81 with SMTP id bu17mr3076129wjb.3.1421142931568; Tue, 13 Jan 2015 01:55:31 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id fi10sm6586536wib.13.2015.01.13.01.55.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jan 2015 01:55:31 -0800 (PST) Message-ID: <54B4EB92.40209@6wind.com> Date: Tue, 13 Jan 2015 10:55:30 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: "Liu, Jijiang" 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> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Tue, 13 Jan 2015 09:55:31 -0000 Hi Jijiang, On 01/13/2015 04:04 AM, Liu, Jijiang wrote: > 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 testpmd flag that is used in the process of analyzing incoming packet., the pseudo-codes are list below, > > If (sw-tunnel-mode) > > Csum fwd engine will analyze if incoming packet is a tunneling packet. > tunnel = 1; > else > Csum fwd engine will not analyze if incoming packet is a tunneling packet, and treat all the incoming packets as non-tunneling packets. > It is used for A. What about "recognize-tunnel" instead of "sw-tunnel-mode"? Or "parse-tunnel"? To me, using "sw-" or "hw-" prefix is confusing because in any case the checksums can be calculated in software or hardware depending on "tx_checksum set outer-ip hw|sw". Moreover, this command has an impact on receive side, but the name is still "tx_checksum". Maybe this is also confusing. > For command 2, If the hw-tunnel-mode is set/clear, which will set/clear a testpmd flag that is used in the process of how to handle tunneling packet, the pseudo-codes are list below, > > if (tunnel == 1) { // this is a tunneling packet > If (hw-tunnel-mode) > ol_flags |= 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 offload flag, which means tell HW to treat the packet as ordinary (non-tunnelled) packet. > It is used for B.2 > } What about: tx_checksum set tunnel-method normal|outer It would select if we use lX_len or outer_lX_len. Is it what you mean? And this only makes sense when we use hw checksum right? >> And will it be possible to support future hardware that will be able to compute >> both outer l3, outer l4, l3 and l4 checksums? > > Yes. > Currently, i40e support outer l3, outer l4, l3 and l4 checksums offload at the same time. I probably missed something here: we only have PKT_TX_OUTER_IP_CKSUM but there is no PKT_TX_OUTER_UDP_CKSUM. Is outer UDP checksum supported > 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. I don't understand why. Could you detail it? >> I have another idea, please let me know if you find it clearer or not. >> The commands format would be: >> >> tx_checksum ... >> >> [...] >> >> 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. I don't think it's really a problem. The cmdline library supports string list, so can have the following 3 commands definitions: 1. tx_checksum ip-udp|ip-tcp|ip-sctp|vxlan-ip-udp|vxlan-ip-tcp|vxlan-ip-sctp l3 off|sw|hw l4 off|sw|hw 2. tx_checksum ip-other|vxlan-ip-other l3 off|sw|hw 3. tx_checksum vxlan outer-l3 off|sw|hw outer-l4 off|sw|hw Maybe 1 and 2 could be splitted in non-vxlan and vxlan. But only the structure should be redefined to have a different help string, not the callback function. > Other question: > > Currently, the following testpmd flag is for per port, not for per packet type, when they are set, which will affect whole port, not just for packet type or format, if you add option in cmdline, which means you have 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 We can add a portid in each command. > Of course, it is welcome if you can send this patch set with this idea for community review. Let's first agree on the user API :) Regards, Olivier