[dpdk-dev] [PATCH v12 0/6] add Tx preparation

[Yong Wang]

> -----Original Message-----
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Wednesday, December 7, 2016 2:03 AM
> To: Yigit, Ferruh <ferruh.yigit at intel.com>; Yong Wang
> <yongwang at vmware.com>; Thomas Monjalon
> <thomas.monjalon at 6wind.com>
> Cc: Harish Patil <harish.patil at qlogic.com>; dev at dpdk.org; Rahul Lakkireddy
> <rahul.lakkireddy at chelsio.com>; Stephen Hurd
> <stephen.hurd at broadcom.com>; Jan Medala <jan at semihalf.com>; Jakub
> Palider <jpa at semihalf.com>; John Daley <johndale at cisco.com>; Adrien
> Mazarguil <adrien.mazarguil at 6wind.com>; Alejandro Lucero
> <alejandro.lucero at netronome.com>; Rasesh Mody
> <rasesh.mody at qlogic.com>; Jacob, Jerin <Jerin.Jacob at cavium.com>;
> Yuanhan Liu <yuanhan.liu at linux.intel.com>; Kulasek, TomaszX
> <tomaszx.kulasek at intel.com>; olivier.matz at 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.ananyev at intel.com]
> > >> Sent: Sunday, December 4, 2016 4:11 AM
> > >> To: Yong Wang <yongwang at vmware.com>; Thomas Monjalon
> > >> <thomas.monjalon at 6wind.com>
> > >> Cc: Harish Patil <harish.patil at qlogic.com>; dev at dpdk.org; Rahul
> Lakkireddy
> > >> <rahul.lakkireddy at chelsio.com>; Stephen Hurd
> > >> <stephen.hurd at broadcom.com>; Jan Medala <jan at semihalf.com>;
> Jakub
> > >> Palider <jpa at semihalf.com>; John Daley <johndale at cisco.com>;
> Adrien
> > >> Mazarguil <adrien.mazarguil at 6wind.com>; Alejandro Lucero
> > >> <alejandro.lucero at netronome.com>; Rasesh Mody
> > >> <rasesh.mody at qlogic.com>; Jacob, Jerin <Jerin.Jacob at cavium.com>;
> > >> Yuanhan Liu <yuanhan.liu at linux.intel.com>; Kulasek, TomaszX
> > >> <tomaszx.kulasek at intel.com>; olivier.matz at 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?
> > >>
> > >>
> > >