On 2 Mar 2026, at 11:54, Eli Britstein wrote:

> Acked-by: Eli Britstein <[email protected]>

Thanks for the review, Eli. However, we cannot apply this until the dependent 
patch is reviewed (see commit message below). If you have some time, could you 
or Gaetan please take a look so we can move this forward?

Cheers,
Eelco

> On 02/03/2026 10:30, 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 *ingress_netdev,
>>                                        struct dp_packet *packet,
>>                                        ovs_be16 *src_port);
>>
>> The callback is invoked during tunnel push operations when hardware offload
>> is enabled and the original ingress port is known. It receives:
>>    - ingress_netdev: The original ingress port where the packet was received
>>    - packet: The inner packet to be encapsulated
>>
>> If the provider implements this callback and returns true, the returned
>> src_port value is used. Otherwise, OVS falls back to the standard hash-based
>> source port calculation.
>>
>> NOTE: This patch needs to be applied on top of the patch series below:
>>      https://patchwork.ozlabs.org/project/openvswitch/list/?series=491639
>>
>> Signed-off-by: Eelco Chaudron <[email protected]>

[...]

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to