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

Olivier Matz olivier.matz at 6wind.com
Mon Jan 22 13:46:38 CET 2018


Hi,

On Tue, Jan 16, 2018 at 07:06:15PM +0000, Shahaf Shuler wrote:
> 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). 

I think that's partially true. Let me try to clarify:

- in case of VXLAN (my previous example), the hw needs to update the
  outer L3 (ip length) and L4 (udp length and optionnally checksum)
- in case of GRE, an update of the checksum is required if present. The
  sequence number may also be increased (I don't know how widely it is
  used).
- in case of a proprietary or unsupported tunnel, the hardware cannot
  know which fields to update in the outer header. So I'm not sure
  a "generic" flag is possible.

How can the application know which tunnels types are supported by the
hardware and which should be done in software?


Olivier


More information about the dev mailing list