On 4/27/25 9:51 AM, Roi Dayan via dev wrote:
> From: Eli Britstein <el...@nvidia.com>
>
> According to [1], transport port masks are optimized using a prefix tree,
> to get less specific datapath flows. However, this might be not optimal
> for some cases. HW offload that is based on templates and has a table per
> template (all the fields that are matched) will create many such tables
> and yield poor performance. Furthermore, such templates are limited resources.
>
> In such cases, it is preferred to have more specific datapath flows that
> share the same match template rather then less flows distributed across
> multiple templates.
>
> To achieve that, introduce other_config:disable-ports-trie (true/false)
> configuration (default as false).
>
> [1] 69d6040e861a ("lib/classifier: Use a prefix tree to optimize ports
> wildcarding.")
>
> Acked-by: Roi Dayan <r...@nvidia.com>
> Signed-off-by: Eli Britstein <el...@nvidia.com>
Hi, Eli and Roi. Thanks for the patch!
I think, it's reasonable to provide an option to turn off prefix matching
for ports, since we allow to do that for other fields. A few comments for
the implementation:
1. We configure prefixes per flow table, so this new option should be at
the same level as a new column in the Flow_Table table. Ideally, we would
just allow configuration through the 'prefixes' column, but it doesn't
really fit in these as it is not a single field, and also we can't just
turn off this by default and expect users to add new prefixes. So, yeah,
adding a new column like 'use-port-prefixes' with a default 'true' value,
is likely a good way forward. Note: "positive" names like "enable/use-..."
are normally easier to understand than the "negative" ("disable-...") ones.
2. There shouldn't be a need to pass a boolean flag around in all the
lookup calls. It should be enough to set ports_mask_len to zero while
creating subtables. This will also allow changing the value in runtime.
Note: there is a synchronization bug that Numan reported recently, but I'm
working on a fix.
3. The hardware details that you're mentioning in the documentation like
"multiple match templates" are not related to OVS and do not make a lot of
sense for the reader, so should not be in the OVS docs. Related OVS
construct is the "prefixes" column, so it should be mentioned instead.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
