Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads

On Sun, Sep 3, 2017 at 7:45 PM, Tom Herbert [off-list ref] wrote:

quoted

Re all sorts of udp encap, sure, we're all on the less-is-more thing and just
RSS-ing on the ip+udp encap header.

quoted

For GRE, I was trying to fight back that rss-ing on inner, but as
Saeed commented,
we didn't see something simple through which the HW can do spreading. To
make sure I follow, you are saying that if this is gre6 tunneling

It's pretty common that HW does this since GRE is in widespread use for a while.

ECMP? I guess so

quoted

the sender side (ip6_tnl_xmit?) will set the IPv6 flow label in a
similar manner done by udp_flow_src_port? and
if the receiver side hashes on L3 IPv6 src/dst/flow label we'll get
spreading? nice!

As long as the network devices support it.

yeah, hopefully upcoming devices will support the thing

quoted

Still, what do we do with IPv4 GRE tunnels? and what do we do with HW
which isn't capable to RSS on flow label?

Throw it out and buy hardware that supports flow label! ;-)

still, we came across IPv4 GRE customer environments

Seriously though, flow labels are the only reasonable way that RSS can
be supported in IPv6. If a device tries to do DPI on IPv6 then they'll
eventually need to be able to parse of some number of extension
headers which unlike IPv4 is unbounded in size. So there are going to
be circumstances in which a device either doesn't understand an EH, or
the size of EHs blows it parsing buffer limit so it can't do the DPI.
IMO, telling host implementations that we're not allowed to use
extension headers because middleboxes can't support them is
unacceptable...

makes sense to me

Btw, these same arguments apply as to why CHECKSUM_COMPLETE is the
only reasonable way to handle receive checksums in IPv6.

supported on mlx5