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

[Ananyev, Konstantin]

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: http://dpdk.org/dev/patchwork/patch/17184/.
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

 

> 
> > > 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?