rte-flow: unmatched ingress traffic default action

rte-flow: unmatched ingress traffic default action

[Robin Jarry]

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 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?

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

RE: rte-flow: unmatched ingress traffic default action

[Ori Kam]

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

Re: rte-flow: unmatched ingress traffic default action

[Robin Jarry]

Hi Ori,

Ori Kam, Oct 18, 2022 at 09:41:
> > 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.

Oh I was not clear enough. I *don't* use the isolated mode. The "general
expectation" I am referring to seems to be in the non-isolated mode.

> > 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.

This is also in regular (non-isolated) mode?

Thanks!

Robin

RE: rte-flow: unmatched ingress traffic default action

[Ori Kam]

Hi Jarry,

> -----Original Message-----
> From: Robin Jarry <rjarry@redhat.com>
> Sent: Tuesday, 18 October 2022 11:13
> 
> Hi Ori,
> 
> Ori Kam, Oct 18, 2022 at 09:41:
> > > 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.
> 
> Oh I was not clear enough. I *don't* use the isolated mode. The "general
> expectation" I am referring to seems to be in the non-isolated mode.
> 
> > > 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.
> 
> This is also in regular (non-isolated) mode?

No, in non-isolated mode PMD will insert default rules based on the configuration,
for example matching on the mac/vlan

Best,
Ori
> 
> Thanks!
> 
> Robin

Re: rte-flow: unmatched ingress traffic default action

[Robin Jarry]

Ori Kam, Oct 18, 2022 at 11:16:
> > This is also in regular (non-isolated) mode?
>
> No, in non-isolated mode PMD will insert default rules based on the
> configuration, for example matching on the mac/vlan

And eventually redirecting packets in queues following the RSS
configuration?

Do you think this is something that can be relied upon across different
PMDs/NICs?

RE: rte-flow: unmatched ingress traffic default action

[Ori Kam]

> -----Original Message-----
> From: Robin Jarry <rjarry@redhat.com>
> Sent: Tuesday, 18 October 2022 12:36
> 
> Ori Kam, Oct 18, 2022 at 11:16:
> > > This is also in regular (non-isolated) mode?
> >
> > No, in non-isolated mode PMD will insert default rules based on the
> > configuration, for example matching on the mac/vlan
> 
> And eventually redirecting packets in queues following the RSS
> configuration?

Yes.

> 
> Do you think this is something that can be relied upon across different
> PMDs/NICs?

Unless I'm missing something, yes this is the basis of DPDK.
(I assume you are talking about non-isolated mode)

Re: rte-flow: unmatched ingress traffic default action

[Robin Jarry]

Ori Kam, Oct 18, 2022 at 12:11:
> > Do you think this is something that can be relied upon across
> > different PMDs/NICs?
>
> Unless I'm missing something, yes this is the basis of DPDK. (I assume
> you are talking about non-isolated mode)

Yes I am. Thanks a lot for the precisions.