Hi Oliver, Xueming,

Tuesday, January 16, 2018 7:29 PM, Xueming(Steven) Li:

quoted

Hi Xueming,

On Tue, Jan 09, 2018 at 10:11:08PM +0800, Xueming Li wrote:

quoted

  */
 #define DEV_TX_OFFLOAD_SECURITY         0x00020000
+/**< Device supports arbitrary tunnel chksum and tso offloading w/o

knowing

quoted

+ *   tunnel detail. Checksum and TSO are calculated based on mbuf

fields:

quoted

+ *     l*_len, outer_l*_len
+ *     PKT_TX_OUTER_IPV6, PKT_TX_IPV6
+ *     PKT_TX_IP_CKSUM, PKT_TX_TCP_CKSUM, PKT_TX_UDP_CKSUM
+ *   When set application must guarantee correct header fields, no need

to

quoted

+ *   specify tunnel type PKT_TX_TUNNEL_* for HW.
+ */

I think some documentation is missing here.
What the NIC needs to know to support the generic tunnel TSO and checksum offloads is:
1. the length of each header
2. the type of the outer/inner l3/l4. Meaning is it IPv4/IPv6 and whether it is UDP/TCP.

The outer IPv6 seems covered. The inner L4 seems missing. 

More details about this offload below.

quoted

quoted

+#define DEV_TX_OFFLOAD_GENERIC_TNL_CKSUM_TSO	0x00040000

 struct rte_pci_device;

I'd like to have more details about this flag and its meaning.

Let's say we want to do TSO on the following vxlan packet:
  Ether / IP1 / UDP / VXLAN / Ether / IP2 / TCP / Data

With the current API, we need to pass the tunnel type to the hardware
with the flag PKT_TX_TUNNEL_VXLAN. Thanks to that, the driver can
forward this information to the hardware so it knows that the
ip1->length, udp->length and optionally the udp->chksum have to be
updated for each generated segment.

With your proposal, if I understand properly, it is not expected to
pass the tunnel type in the mbuf. So how can the hardware know if some
fields have to be updated in the outer header?

I'm not expert on hardware, the driver has to supply outer and inner
L3/L4 offsets, types and which field(s) to fill checksum, no length update as
far as I know.

Mellanox HW is capable to parse the packet according to hints from the driver.

If you think about it, to calculate the IP checksum all you need to do is know the inner/outer IP offset, and the fact it is an IPv4.
To calculate the inner TCP/UDP checksum it is the same. all that after the L4 is counted as payload and the pseudo header can be done with the information about the IP.

About TSO - just need to get the offset till the inner header so that the NIC can append the full headers to every segment and update the inner/outer L3 and L4 fields accordingly (which their location is known). 

All of this can be done by the mbuf fields. Given those fields the driver can calculate the:
Outer_l3_offset = outer_l2_len
Outer_l4_offlset = outer_l3_offset +  outer_l3_len
Inner_l3_offset = outer_l4_offset + l2_len 
Inner_l4_offset = inner_l4_offset + l3_len

And pass to the device. Theoretically multiple encapsulating are supported by enlarging the l2_len. 
 
Hope it explains more about this generic offload.