[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load

[Ananyev, Konstantin]

Hi lads,

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Monday, February 15, 2016 10:03 AM
> To: Lu, Wenzhuo
> Cc: dev at dpdk.org; Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load
> 
> 2016-02-15 05:32, Lu, Wenzhuo:
> > From: Ananyev, Konstantin
> > > From reading X550 spec, I don't really understand what for we need to specify is
> > > it GRE or VXLAN packet, so probably we don't need that flag for now at all?
> > The reason is we need to set the tunnel type in the Advanced Transmit Data Descriptor.

Yes, I saw that in x550 spec, though I really doubt it is needed to calculate etiher outer IP,
or inner IP/L4 checksum.
After all TUNNELLEN includes all tunnel headers plus inner L2 length.
The only reason I can think it might be useful for  HW is when packets are sent from one
VF to another. 
In that case, HW probably would try to avoid extra packet scanning and rely on information from SW.
As mentioned in x550 spec, section's  note:
"...In virtualization mode, packets might be received from other local VMs. The X550 does not
check the L5 header for these packets and does not report NFS header. If such packets carry
IP tunneling (IPv4 - IPv6), they are reported as IPV4E. The packets received from local VM
are indicated by the LB bit in the status field. To be identified, the CC bit in the transmit
descriptor must be set and if it is a tunnel packet, the TUNNEL.OUTERIPCS must be set also."
Though I am not sure we do need to support that case.
That's why probably the easiest way would be to avoid setting 'Tunnel Type' field at all.

> 
> Why don't we use packet type?

Yes, that's probably another possible way, if we really decide to setup this info at TX descriptor.

BTW, reading x550 spec, I think ixgbe RX code that setups packet_type need to be updated too.
Right now it can't handle vxlan/gre tunnelling case.

Konstantin

> 
> > > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM (as enum)
> > > and reserve few values for future expansion (2 or 3 bits?).
> > Now there're only VxLAN and NVGRE supported. So, only 1 bit is occupied for that. Not sure if more types will be supported in the
> future. Any suggestions? Thanks.
> 
> Yes there can be a lot of tunnel types.
> Please check RTE_PTYPE_TUNNEL_*
>