On 19 Feb 2026, at 11:08, Eli Britstein wrote:
> On 18/02/2026 11:55, Eelco Chaudron wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> This patch introduces a new API to the offload provider framework that
>> allows hardware offload implementations to control UDP tunnel source port
>> selection during tunnel encapsulation.
>>
>> Background and Motivation
>> ==========================
>>
>> UDP-based tunnels (VXLAN, Geneve, etc.) use the UDP source port as an
>> entropy field to enable ECMP load balancing across multiple paths in the
>> network. The source port is typically calculated by hashing packet header
>> fields (5-tuple or inner packet headers) to distribute flows across
>> different paths.
>>
>> However, hardware offload implementations may require different approaches
>> to source port calculation:
>>
>> 1. Hardware NICs may use different hash functions or hash inputs than
>> the software datapath, which can lead to inconsistent flow distribution
>> when mixing hardware and software paths.
>>
>> 2. Some hardware may support enhanced entropy mechanisms (e.g., using
>> additional packet fields or hardware-specific hash engines) that provide
>> better load distribution than the default software implementation.
>>
>> Design
>> ======
>>
>> This patch adds a new optional callback to the dpif_offload_class:
>>
>> bool (*netdev_udp_tnl_get_src_port)(const struct dpif_offload *,
>> const struct netdev *orig_in_port,
>> const struct netdev *tunnel_port,
>> const struct dp_packet *packet,
>> ovs_be16 *src_port);
>
> the "orig_in_port"'s name is not consistent. in some places like this, in
> others, "orig_in_netdev".
>
> i suggest ingress_netdev, or orig_netdev (and ingress/orig_port where it is
> actually a port, not a netdev).
Thanks for the feedback, I already cleaned this up as I was working on a
follow on patch for the dp-hash. Will wrap it up, and send out an updated
non-RFC patch some time next week.
> regarding "tunnel_port", should also follow to be "netdev", or removed
> completely.
>
> it is not in use for "dummy". it won't be in use for "doca". i also don't see
> how it might be in any future use.
Makes sense, I'll remove it, and we can always add it if it's needed in the
future.
//Eelco
[...]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
