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
