On 10/13/26 12:14 PM, Dumitru Ceara via dev wrote:
> Megaflows matching on these are not offloadable on specific hardware
> NICs. These were originally introduced by 20a96b9d2c3d ("northd: Allow
> fragmented traffic through LB.") in order to address the fact that with
> the userspace datapath fragmented IP packets miss L4 headers in later
> fragments, breaking load balancing. A follow up commit, 8e6f9a8355e2
> ("northd: Fix HW offload problem related to ct_tuple."), tried to
> address the offload issue but missed to add a check to only send the
> first packet of a session (ct_state=+new) to the CT EXTRACT side table
> if and only if it is a fragmented IP packet.
>
> That means that ct_tuple matches would always be present for
> megaflows forwarding unidirectional UDP traffic, even if the IP packets
> are not fragmented. Some hardware NICs may be capable of offloading
> such traffic (see the first Reported-at link) but only if their
> megaflows don't match on ct_tuple fields.
>
> A previous patch attempted to fix a similar issue by limiting switch
> conntrack tuple fields extraction only to traffic destined to load
> balancers that are configured with L4 ports. That approach has some
> downsides and requires an additional logical flow for each load balancer
> VIP.
>
> This patch attempts fixing the issue in a different, a bit more generic
> way: it turns out we don't need to send all ct_state=+new traffic to
> the CT EXTRACT table, we should instead do that only for fragments.
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2026-October/054041.html
> Reported-at:
> https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/
> Reported-at: https://redhat.atlassian.net/browse/FDP-4458
> Fixes: 20a96b9d2c3d ("northd: Allow fragmented traffic through LB.")
> Fixes: 8e6f9a8355e2 ("northd: Fix HW offload problem related to ct_tuple.")
> Assisted-by: Claude Opus 4.6, OpenCode
> Signed-off-by: Dumitru Ceara <[email protected]>
> ---
As mentioned on ovs-discuss [0], it would be great to have confirmation
that this addresses the vendor-specific issue before we merge this patch
(if acked).
[0]
https://mail.openvswitch.org/pipermail/ovs-discuss/2026-October/054049.html
Regards,
Dumitru
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
