nit: the patch 'area' should be 'odp-execute' instead of userspace datapath'.
On 8/31/26 5:18 PM, Tim Rozet via dev wrote: > The userspace implementation of OVS_HASH_ALG_SYM_L4 calls > flow_hash_symmetric_l3l4() with UDP port hashing disabled. As a > result, UDP packets with identical addresses but different ports > receive the same datapath hash. > > The Linux datapath implements this algorithm with > __skb_get_hash_symmetric(). Its symmetric flow dissector requests > FLOW_DISSECTOR_KEY_PORTS, and skb_flow_get_ports() extracts source > and destination ports for IPPROTO_UDP. Thus, the two datapaths use > different hash fields for the same OVS action. Technically, it's more of a kernel bug than OVS. Ports in UDP, especially in case of the tunneling (which is your target use case) are not symmetric. So, when user asks for symmetric hashing we omit the UDP ports to make sure the hashes in both directions actually match. That's why historically OVS always distinguishes symmetric_l3l4 vs the symmetric_l3l4+udp hash algorithms for bundles and other OpenFlow constructs, providing options for users that need one behavior or another. We're a little limited though with what we can add into the kernel as we're bound to reuse existing kernel facilities as possible. That's why the L4 symmetric dp_hash in the kernel (that came way after the userspace one) defaulted to the existing flow dissector and caused difference between the two implementations. As it is not defined how the dh_hash algorithms supposed to work in details, it is generally OK that they differ between implementations. We're also falling back to the simple HASH in case SYM_L4 is not available. At the same time I agree that it would be nice if algorithms in both userspace and the kernel were acting in the similar fashion. There are two ways out of this situation: 1. Add a new symmetric_l4+udp algorithm for the dp_hash. 2. Change the behavior of the current SYM_L4 so it includes UDP ports as it is done in this patch. First option would require some renaming and dance around falling back to a current SYM_L4 when not supported. This is likely how it should've been done in the first place, but it would be a very awkward solution right now. The second one seems indeed more reasonable. I am not sure if it is very important to have a true symmetric hashing for the dp_hash use cases. However, same as the first option, it is not a bug fix, but a change in user-visible behavior. This means it goes on main with a NEWS entry covering the change as there could be people relying on the current truly symmetric hashing. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
