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

[Shahaf Shuler]

Monday, January 22, 2018 2:47 PM, Olivier Matz:
> 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?

Yes I understand your point. maybe we should rephrase and change the name of the feature. 

The support from the device is for inner and outer checksums on IPV4/TCP/UDP and TSO for *any packet with the following format*:

< some headers > / [optional IPv4/IPv6] / [optional TCP/UDP] / <some headers> / [optional inner IPv4/IPv6] / [optional TCP/UDP]

 For example the following packets can use this feature:

1. eth / ipv4 / udp / VXLAN / ip / tcp
2. eth / ipv4 / GRE / MPLS / ipv4 / udp 


> 
> 
> Olivier