On Sun, Sep 3, 2017 at 7:45 PM, Tom Herbert <t...@herbertland.com> wrote: >> 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.
>> 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 >> 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 >> 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
