From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ferruh.yigit@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 5129E2B8F for <dev@dpdk.org>; Wed, 7 Dec 2016 10:57:18 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 07 Dec 2016 01:57:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="14790389" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by orsmga002.jf.intel.com with ESMTP; 07 Dec 2016 01:57:13 -0800 To: Yong Wang <yongwang@vmware.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Thomas Monjalon <thomas.monjalon@6wind.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <D4643DF5.B8241%Harish.Patil@cavium.com> <2601191342CEEE43887BDE71AB9772583F0E2444@irsmsx105.ger.corp.intel.com> <3517413.XL3bTbAyaC@xps13> <BY2PR05MB235922FD3B25185FFA3BAD1EAF8E0@BY2PR05MB2359.namprd05.prod.outlook.com> <2601191342CEEE43887BDE71AB9772583F0E3B03@irsmsx105.ger.corp.intel.com> <BY2PR05MB2359E2D5220CACCC5A377D8DAF820@BY2PR05MB2359.namprd05.prod.outlook.com> Cc: Harish Patil <harish.patil@qlogic.com>, "dev@dpdk.org" <dev@dpdk.org>, Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>, Stephen Hurd <stephen.hurd@broadcom.com>, Jan Medala <jan@semihalf.com>, Jakub Palider <jpa@semihalf.com>, John Daley <johndale@cisco.com>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, Alejandro Lucero <alejandro.lucero@netronome.com>, Rasesh Mody <rasesh.mody@qlogic.com>, "Jacob, Jerin" <Jerin.Jacob@cavium.com>, Yuanhan Liu <yuanhan.liu@linux.intel.com>, "Kulasek, TomaszX" <tomaszx.kulasek@intel.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com> From: Ferruh Yigit <ferruh.yigit@intel.com> Message-ID: <8b0acf96-cba9-6c91-92c4-93674052e995@intel.com> Date: Wed, 7 Dec 2016 09:57:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <BY2PR05MB2359E2D5220CACCC5A377D8DAF820@BY2PR05MB2359.namprd05.prod.outlook.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 07 Dec 2016 09:57:18 -0000 On 12/6/2016 6:25 PM, Yong Wang wrote: >> -----Original Message----- >> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] >> Sent: Sunday, December 4, 2016 4:11 AM >> To: Yong Wang <yongwang@vmware.com>; Thomas Monjalon >> <thomas.monjalon@6wind.com> >> Cc: Harish Patil <harish.patil@qlogic.com>; dev@dpdk.org; Rahul Lakkireddy >> <rahul.lakkireddy@chelsio.com>; Stephen Hurd >> <stephen.hurd@broadcom.com>; Jan Medala <jan@semihalf.com>; Jakub >> Palider <jpa@semihalf.com>; John Daley <johndale@cisco.com>; Adrien >> Mazarguil <adrien.mazarguil@6wind.com>; Alejandro Lucero >> <alejandro.lucero@netronome.com>; Rasesh Mody >> <rasesh.mody@qlogic.com>; Jacob, Jerin <Jerin.Jacob@cavium.com>; >> Yuanhan Liu <yuanhan.liu@linux.intel.com>; Kulasek, TomaszX >> <tomaszx.kulasek@intel.com>; olivier.matz@6wind.com >> Subject: RE: [dpdk-dev] [PATCH v12 0/6] add Tx preparation >> >> Hi >> >> >> >>>> >> >>>> 2016-11-30 17:42, Ananyev, Konstantin: >> >>>>>>> Please, we need a comment for each driver saying >> >>>>>>> "it is OK, we do not need any checksum preparation for TSO" >> >>>>>>> or >> >>>>>>> "yes we have to implement tx_prepare or TSO will not work in this >> >>>> mode" >> >>>>>>> >> >>>>>> >> >>>>>> qede PMD doesn’t currently support TSO yet, it only supports Tx >> >>>> TCP/UDP/IP >> >>>>>> csum offloads. >> >>>>>> So Tx preparation isn’t applicable. So as of now - >> >>>>>> "it is OK, we do not need any checksum preparation for TSO" >> >>>>> >> >>>>> Thanks for the answer. >> >>>>> Though please note that it not only for TSO. >> >>>> >> >>>> Oh yes, sorry, my wording was incorrect. >> >>>> We need to know if any checksum preparation is needed prior >> >>>> offloading its final computation to the hardware or driver. >> >>>> So the question applies to TSO and simple checksum offload. >> >>>> >> >>>> We are still waiting answers for >> >>>> bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3. >> >>> >> >>> The case for a virtual device is a little bit more complicated as packets >> offloaded from a virtual device can eventually be delivered to >> >>> another virtual NIC or different physical NICs that have different offload >> requirements. In ESX, the hypervisor will enforce that the packets >> >>> offloaded will be something that the hardware expects. The contract for >> vmxnet3 is that the guest needs to fill in pseudo header checksum >> >>> for both l4 checksum only and TSO + l4 checksum offload cases. >> >> >> >> Ok, so at first glance that looks to me very similar to Intel HW requirements. >> >> Could you confirm would rte_net_intel_cksum_prepare() >> >> also work for vmxnet3 or some extra modifications are required? >> >> You can look at it here: https://urldefense.proofpoint.com/v2/url?u=http- >> 3A__dpdk.org_dev_patchwork_patch_17184_&d=DgIGaQ&c=uilaK90D4TOV >> oH58JNXRgQ&r=v4BBYIqiDq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=NS >> 4zOl2je_tyGhnOJMSnu37HmJxOZf-1KLYcVsu8iYY&s=dL-NOC- >> 18HclXUURQzuyW5Udw4NY13pKMndYvfgCfbA&e= . >> >> Note that for Intel HW the rules for pseudo-header csum calculation >> >> differ for TSO and non-TSO case. >> >> For TSO length inside pseudo-header are set to 0, while for non-tso case >> >> It should be set to L3 payload length. >> >> Is it the same for vmxnet3 or no? >> >> Thanks >> >> Konstantin >> > > Yes and this is the same for vmxnet3. > This means vmxnet3 PMD also should be updated, right? Should that update be part of tx_prep patchset? Or separate patch? >>> >> >>>>> This is for any TX offload for which the upper layer SW would have >> >>>>> to modify the contents of the packet. >> >>>>> Though as I can see for qede neither PKT_TX_IP_CKSUM or >> >>>> PKT_TX_TCP_CKSUM >> >>>>> exhibits any extra requirements for the user. >> >>>>> Is that correct? >> >> >