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
