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 D3F927E9D for ; Mon, 10 Nov 2014 16:48:19 +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.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XnrOo-0001lz-3R; Mon, 10 Nov 2014 17:01:06 +0100 Message-ID: <5460E07F.6060303@6wind.com> Date: Mon, 10 Nov 2014 16:57:51 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Ananyev, Konstantin" , Yong Wang , "Liu, Jijiang" References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> <54588BF7.309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8510E@SHSMSX101.ccr.corp.intel.com>, <5459FBB2.1040408@6wind.com> <0c654d2c0d304b45a40af6ca38b70adf@EX13-MBX-026.vmware.com> <545CFE56.60605@6wind.com> <2601191342CEEE43887BDE71AB977258213A38D2@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213A38D2@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload 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, 10 Nov 2014 15:48:20 -0000 Hello Konstantin, >> By the way, we had the same kind of discussion with Konstantin [1] >> about what to do with the TCP checksum. My feeling is that setting it >> to the pseudo-header checksum is the best we can do: >> - linux does that >> - many hardware requires that (this is not the case for ixgbe, which >> need a pshdr checksum without the IP len) >> - it can be reused if received by a virtual device and sent to a >> physical device supporting TSO > > Yes, I remember that discussion. > I still think we better avoid any read/write access of the packet data inside PMD TX routine. > (packet header parsing and/or pseudo-header checksum calculations). > As I said before - if different HW have different requirements of what have to be recalculated for HW TX offloads - > why not introduce a new function dev_prep_tx(portid, queueid, mbuf[], num)? > PMD developer can put all necessary calculations/updates of the packet data and related mbuf fields inside that function. > It would be then a PMD responsibility to provide that function and it would be an app layer responsibility to call it for > mbufs with TX offload flags before calling tx_burst(). I think I understand your point: you don't want to touch the packet in the PMD because the lcore that transmits the packet can be different than the one that built it. In this case (i.e. a pipeline case), reading or writing the packet can produce a cache miss, is it correct? >>From an API perspective, it looks a bit more complex to have to call dev_prep_tx() before sending the packets if they have been flagged for offload processing. But I admit I have no other argument. I'll be happy to have more comments from other people on the list. I'm sending a first version of the patchset now as it's ready, it does not take in account this comment, but I'm open to add it in a v2 if there is a consensus on this. Now, knowing that: - adding dev_prep_tx() will also concern hw checksum (TCP L4 checksum already requires to set the TCP pseudo header checksum), so adding this will change the API of an existing feature - TSO is a new feature expected for 1.8 (which should be out soon) Do you think we need to include this for 1.8 or can we postpone your proposition for after the 1.8 release? Thank you for your comments, Regards, Olivier >> [1] http://dpdk.org/ml/archives/dev/2014-May/002766.html