[dpdk-dev] [PATCH 4/6] ethdev: introduce TX common tunnel offloads

Shahaf Shuler shahafs at mellanox.com
Tue Jan 16 20:06:15 CET 2018


Hi Oliver, Xueming,

Tuesday, January 16, 2018 7:29 PM, Xueming(Steven) Li:
> > Hi Xueming,
> >
> > On Tue, Jan 09, 2018 at 10:11:08PM +0800, Xueming Li wrote:
> > >   */
> > >  #define DEV_TX_OFFLOAD_SECURITY         0x00020000
> > > +/**< Device supports arbitrary tunnel chksum and tso offloading w/o
> > knowing
> > > + *   tunnel detail. Checksum and TSO are calculated based on mbuf
> > fields:
> > > + *     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
> > > + *   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.

> > > +#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. 





More information about the dev mailing list