Tom Herbert <t...@herbertland.com> writes: > An encapsulator sets the UDP source port to be the flow entropy of the > packet being encapsulated. So when the packet traverses the network > devices can base their hash just on the canonical 5-tuple which is > sufficient for ECMP and RSS. IPv6 flow label is even better since the > middleboxes don't even need to look at the transport header, a packet > is steered based on the 3-tuple of addresses and flow label. In the > Linux stack, udp_flow_src_port is used by UDP encapsulations to set > the source port. Flow label is similarly set by ip6_make_flowlabel. > Both of these functions use the skb->hash which is computed by calling > flow dissector at most once per packet (if the packet was received > with an L4 HW hash or locally originated on a connection the hash does > not need to be computed).
This would require the MPLS stack copying the flowlabel of IPv6 connections between MPLS routers over their whole lifetime in the MPLS network. The same would hold for MPLS encapsulated inside UDP, the source port needs to be kept constant. This is very impractical. The hash for the flow label can often not be recomputed by interim routers, because they might lack the knowledge of the upper layer protocol. UDP source port entropy still has the problem that we don't respect the source port as RSS entropy by default in network cards, because of possible fragmentation and thus possible reordering of packets. GRE does not have this problem and is way easier to identify by hardware. Basically we need to tell network cards that they can use specific destination UDP ports where we allow the source port to be used in RSS hash calculation. I don't see how this is any easier than just using GRE with a defined protocol field? I do like the combination of ipv6 flowlabel + GRE. Btw. people are using the GRE Key as additional entropy without looking into the GRE payload. Bye, Hannes
