> -----Original Message----- > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com] > Sent: Wednesday, December 7, 2016 2:03 AM > To: Yigit, Ferruh <ferruh.yi...@intel.com>; Yong Wang > <yongw...@vmware.com>; Thomas Monjalon > <thomas.monja...@6wind.com> > Cc: Harish Patil <harish.pa...@qlogic.com>; dev@dpdk.org; Rahul Lakkireddy > <rahul.lakkire...@chelsio.com>; Stephen Hurd > <stephen.h...@broadcom.com>; Jan Medala <j...@semihalf.com>; Jakub > Palider <j...@semihalf.com>; John Daley <johnd...@cisco.com>; Adrien > Mazarguil <adrien.mazarg...@6wind.com>; Alejandro Lucero > <alejandro.luc...@netronome.com>; Rasesh Mody > <rasesh.m...@qlogic.com>; Jacob, Jerin <jerin.ja...@cavium.com>; > Yuanhan Liu <yuanhan....@linux.intel.com>; Kulasek, TomaszX > <tomaszx.kula...@intel.com>; olivier.m...@6wind.com > Subject: RE: [dpdk-dev] [PATCH v12 0/6] add Tx preparation > > > Hi Ferruh, > > > > > On 12/6/2016 6:25 PM, Yong Wang wrote: > > >> -----Original Message----- > > >> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com] > > >> Sent: Sunday, December 4, 2016 4:11 AM > > >> To: Yong Wang <yongw...@vmware.com>; Thomas Monjalon > > >> <thomas.monja...@6wind.com> > > >> Cc: Harish Patil <harish.pa...@qlogic.com>; dev@dpdk.org; Rahul > Lakkireddy > > >> <rahul.lakkire...@chelsio.com>; Stephen Hurd > > >> <stephen.h...@broadcom.com>; Jan Medala <j...@semihalf.com>; > Jakub > > >> Palider <j...@semihalf.com>; John Daley <johnd...@cisco.com>; > Adrien > > >> Mazarguil <adrien.mazarg...@6wind.com>; Alejandro Lucero > > >> <alejandro.luc...@netronome.com>; Rasesh Mody > > >> <rasesh.m...@qlogic.com>; Jacob, Jerin <jerin.ja...@cavium.com>; > > >> Yuanhan Liu <yuanhan....@linux.intel.com>; Kulasek, TomaszX > > >> <tomaszx.kula...@intel.com>; olivier.m...@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? > > Yes, that's right. > > >Should that update > > be part of tx_prep patchset? Or separate patch? > > Another question I suppose is who will do the actual patch for vmxnet3. > Yong, are you ok to do the patch for vmxnet3, or prefer us to do that? > Please note, that in both cases will need your help in testing/reviewing it. > Konstantin
It will be great if you can put together a patch as part of the entire patchset on tx_prep() for vmxnet3 and I will definitely help review it. Regarding testing, I can definitely help but I don't have a testing harness to cover the entire matrix (different ESX version, different vmxnet3 device version, VM-VM, VM-physical over different uplinks, etc.) so it will be limited. Related to this, I have the impression that Intel has some existing coverage for vmxnet3 as well as other NICs. Do we know if that will cover this use case as well? > > > > >>> > > >> > > >>>>> 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? > > >> > > >> > > >