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

[Olivier Matz <olivier.matz@6wind.com>]

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