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 7252619F5 for ; Fri, 9 Jan 2015 11:45:26 +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 1Y9X7h-0005UI-B4; Fri, 09 Jan 2015 11:48:57 +0100 Message-ID: <54AFB13E.2080200@6wind.com> Date: Fri, 09 Jan 2015 11:45:18 +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: "Ananyev, Konstantin" , "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> In-Reply-To: <2601191342CEEE43887BDE71AB977258213D3897@irsmsx105.ger.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: Fri, 09 Jan 2015 10:45:26 -0000 Hi, Thank you Jijiang for taking the time to get back on this. 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 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, ...) Today, the behavior of csum forward engine is defined for any kind of packet. See the description and the table in http://dpdk.org/ml/archives/dev/2014-December/009886.html 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. In my understanding, the use-case you are describing correspond to specific packet types. So a configuration would work only for one packet format only. Is it correct? I think that the test-pmd command API should define a behavior for the csum forward engine for any packet. What do you think? Regards, Olivier