On 19 Dec 2025, at 17:59, Ilya Maximets wrote:
Thanks for the patch Ilya. Some small nit below. The rest looks good to me.
Acked-by: Eelco Chaudron <[email protected]>
> Unlike other fields, the tunnel ones don't really need to be
> unwildcarded on writes (load, move, set_field, stack_pop).
>
> The main reason for unwildcarding other fields is that we have
> optimizations in odp-util that skip generation of set() actions for
> packet fields that didn't change. So, we have to match on them to
> avoid installing an overly broad flow that will swallow unrelated
> traffic that would have the set() action generated.
>
> But this is not the case for tunnel fields, for which the set(tunnel)
> action always contains the full set of required fields. The action
> can be skipped entirely if the tunnel metadata didn't change at all,
> but this is only the case when we're sending a packet to the exact
> same tunnel twice, which is not a problem, as only the second
> set(tunnel) is skipped and all the correct metadata was already set
> by the first one. And sending a packet back to the same tunnel
> without changing any metadata is not really possible, as at least the
> source port will be zeroed out, and is not a reasonable thing to do
> regardless.
>
> Also, all the basic fields that are required to distinguish two tunnel
> ports from each other are exact matched by default in tnl_wc_init().
>
> Let's check if the destination field is a tunnel field and avoid
> unnecessarily unwildcarding them.
>
> This is needed because when the tunnel family changes from IPv4 to
> IPv6, while setting tun_ipv6_src/dst we're unwildcarding those fields
> in the match, making it match on both IPv4 and IPv6 addresses. This
> is fine from the OpenFlow point of view, since all these fields have
> no prerequisites. And the userspace daapath can handle this just fine.
daapath -> datapath
> But Linux kernel datapath is using a union to store the tunnel config
> and so it rejects flows with both IPv4 and IPv6 fields matched.
> This makes it very expensive to bridge IPv4 and IPv6 flow-based
> tunnels together with the kernel datapath, as flow put always fails
> and every packet has to go through userspace.
[...]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev