[dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload
konstantin.ananyev at intel.com
Mon Nov 10 12:39:48 CET 2014
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Friday, November 07, 2014 5:16 PM
> To: Yong Wang; Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload
> Hello Yong,
> On 11/07/2014 01:43 AM, Yong Wang wrote:
> >>> As to HW TX checksum offload, do you have special requirement for implementing TSO?
> >> Yes. TSO implies TX TCP and IP checksum offload.
> > Is this a general requirement or something specific to ixgbe/i40e? FWIW,
> > vmxnet3 device does not support tx IP checksum offload but doe support
> > TSO. In that case, we cannot leave IP checksum field as 0 (the correct
> > checksum needs to be filled in the header) before passing it the the NIC
> > when TSO is enabled.
> This is a good question because we need to define the proper API that
> will work on other PMDs in the future.
> Indeed, there is a hardware specificity in ixgbe: when TSO is enabled,
> the IP checksum flag must also be passed to the driver if it's IPv4.
> From 82599 datasheets (126.96.36.199.4 Advanced Transmit Data Descriptor):
> IXSM (bit 0) - Insert IP Checksum: This field indicates that IP
> checksum must be inserted. In IPv6 mode, it must be reset to 0b.
> If DCMD.TSE and TUCMD.IPV4 are set, IXSM must be set as well.
> If this bit is set, the packet should at least contain an
> IP header.
> If we allow the user to give the TSO flag without the IP checksum
> flag in mbuf flags, the ixgbe driver would have to set the IP checksum
> flag in hardware descriptors if the packet is IPv4. The driver would
> have to parse the IP header: this is not a problem as we already need
> it for TCP checksum.
> To summarize, I think we have 3 options when transmitting a packet to be
> segmented using TSO:
> - set IP checksum to 0 in the application: in this case, it would
> require additional work in virtual drivers if the peer expects
> to receive a packet with a valid IP checksum. But I'm wondering
> what is the need for calculating a checksum when transmitting on
> a virtual device (the peer receiving the packet knows that the
> packet is not corrupted as it comes from memory). Moreover, if the
> device advertise TSO, I assume it can also advertise IP checksum
> - calculate the IP checksum in the application. It would take additional
> cycles although it may not be needed as the driver probably knows
> how to calculate it.
> - if the driver supports both TSO and IP checksum, the 2 flags MUST
> be given to the driver and the IP checksum must be set to 0 and the
> checksum cannot be calculated in software. If the driver only
> supports TSO, the checksum has to be calculated in software.
> Currently, I choosen the first solution, but I'm open to change the
> design. Maybe the 3rd one is also a good solution.
> By the way, we had the same kind of discussion with Konstantin 
> 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().
> Best regards,
>  http://dpdk.org/ml/archives/dev/2014-May/002766.html
More information about the dev