RE: rte-flow: unmatched ingress traffic default action

[Ori Kam <orika@nvidia.com>]

Hi Jarry,

> -----Original Message-----
> From: Robin Jarry <rjarry@redhat.com>
> Sent: Monday, 17 October 2022 17:49
> 
> Hi Ori, all,
> 
> From what I can read in the docs in the "Isolated Mode"[1] section:
> 
> > The general expectation for ingress traffic is that flow rules process
> > it first; the remaining unmatched or pass-through traffic usually ends
> > up in a queue (with or without RSS, locally or in some sub-device
> > instance) depending on the global configuration settings of a port.
> 
> [1]: https://doc.dpdk.org/guides/prog_guide/rte_flow.html#flow-isolated-
> mode
> 
> Should I read "general expectation" as a simple recommendation or is it
> a requirement from the RTE flow API?
> 

I think the wording in the doc should change since it is not clear.
So let me clarify it.
The idea of isolated mode is that the DPDK application will only get traffic that the application actively
requested.
When working in isolated mode (relevant only for ingress traffic), the DPDK port can only receive traffic
that the application configured a matching rule.
If no matching rule was set the packet is moved to the next application/kernel or dropped
if no such application/kernel exists.

> I realize that this eventually will depend on each driver, firmware
> and/or hardware. However, would it be reasonable to rely on such
> a behaviour to implement preemptive queue redirection prior to regular
> RSS?
> 
> For the sake of argument, let's say I have 3 RX queues configured with
> an RSS redirection table set as follows:
> 
>     0 1 0 1 0 1 0 1 0 1 ..... 1 0 1
> 
> And I configure a single flow:
> 
>     struct rte_flow_error error;
>     struct rte_flow *flow;
> 
>     flow = rte_flow_create(
>         port_id,
>         (const struct rte_flow_attr){ .ingress = 1 },
>         (const struct rte_flow_item []) {
>             {
>                 .type = RTE_FLOW_ITEM_TYPE_ETH,
>                 .spec = &(const struct rte_flow_item_eth){
>                     .type = htons(0x1234),
>                 },
>                 .mask = &(const struct rte_flow_item_eth){
>                     .type = htons(0xffff),
>                 },
>             },
>             { .type = RTE_FLOW_ITEM_TYPE_END },
>         },
>         (const struct rte_flow_action actions[]){
>             {
>                 .type = RTE_FLOW_ACTION_TYPE_QUEUE,
>                 .conf = &(const struct rte_flow_action_queue) {
>                     .index = 2,
>                 },
>             },
>             { .type = RTE_FLOW_ACTION_TYPE_END },
>         },
>         &error,
>     );
> 
> Can I expect *all* ingress traffic *not* matching ether_type=0x1234 to
> be redirected to queues 0 and 1 following the default RSS algorithm?
> 

No, all traffic not matching the rule will be moved to the kernel in case of a bifurcated driver,
MLX5 for example, or dropped assuming there is no other application with a matching rule.

> If folks from NIC vendors could comment on their own implementation, it
> would be much appreciated.
> 
> Thanks in advance.
> 
> --
> Robin Jarry
> Principal Software Engineer
> Red Hat

Best,
Ori