From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 2E9E7A0560;
	Mon, 17 Oct 2022 16:48:48 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 110AF40E5A;
	Mon, 17 Oct 2022 16:48:48 +0200 (CEST)
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [170.10.129.124])
 by mails.dpdk.org (Postfix) with ESMTP id 2EA5540143
 for <dev@dpdk.org>; Mon, 17 Oct 2022 16:48:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1666018125;
 h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
 content-transfer-encoding:content-transfer-encoding;
 bh=UpCvgQX+CPcZAIUgec+9LhErIVbXxj4URMocCaEmSxA=;
 b=W1dqu8X69GGtDjp5pFQK5TLYkbKEItsjylwm9joHDI3wiKmNq70k/jl63w1bQII1vxMOw0
 DsLlq4rqzl/D6YgJFgcLTVV1+G1LwJzXH94dBQ1I4XJx8eiiGuLe1BMNAVnXC1PoqDv9OY
 HT2r6mcQip27ej84UXpiyYSs3TGPM44=
Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com
 [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id
 us-mta-471-WT83_3WzOMCuxBff7m2xPA-1; Mon, 17 Oct 2022 10:48:44 -0400
X-MC-Unique: WT83_3WzOMCuxBff7m2xPA-1
Received: by mail-wr1-f69.google.com with SMTP id
 g27-20020adfa49b000000b0022cd5476cc7so3778597wrb.17
 for <dev@dpdk.org>; Mon, 17 Oct 2022 07:48:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:from:subject:message-id:date:content-transfer-encoding
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=UpCvgQX+CPcZAIUgec+9LhErIVbXxj4URMocCaEmSxA=;
 b=pIv2wDHp6Svou/WQazHZHtUc8ZLdQV4EBpugvRDM0xG42javK9VdhqorTvdZTOEeO4
 k13ENv1P4QkukumAYUDfVCdV8jMOl5XBdAghCt+bSm9TjKsDbf8metmXO4Cs3flOLbni
 5wq0r+RCvM1Akyuo2n++fSxHYg3AO8Aj/x4QnHWbAyKN6Uue66xhOOrkZnR9bqxCLDaQ
 Blbi0Dtf54/gpcw23DwVT47nisiF7SxLsjK9I3rfTcjhS49oYRXFn6ZTAypHjgRQ8avV
 5QFvN2xTi2pUQApOZtzb+Zi2UTFE+yWzJZ8OpE8m4FyxjX34rlU2cHSlGP/W5bPv0H3/
 xoPw==
X-Gm-Message-State: ACrzQf31Qky9k2bZVedg1oXu8ntJI5+8M3muPW5+2zPIwAoGsyBhI20t
 1C2d1XQeUEZypfo+D9cgrUJJC2dNELDnlwQ3VSZnVwmP6l+Ox/BrCiu9nYUwIkKdol8n4gaTuxQ
 uuuY=
X-Received: by 2002:a05:600c:35ce:b0:3c6:809a:b5c3 with SMTP id
 r14-20020a05600c35ce00b003c6809ab5c3mr7614093wmq.206.1666018123608; 
 Mon, 17 Oct 2022 07:48:43 -0700 (PDT)
X-Google-Smtp-Source: AMsMyM7F+T36O7phtkNZPVSSPnNRFzgYZ8JgNtM6O4ahl6jgyjLhQdftPUmZXU4G++NjaCu8aYJcJw==
X-Received: by 2002:a05:600c:35ce:b0:3c6:809a:b5c3 with SMTP id
 r14-20020a05600c35ce00b003c6809ab5c3mr7614075wmq.206.1666018123424; 
 Mon, 17 Oct 2022 07:48:43 -0700 (PDT)
Received: from localhost (2a01cb000f483e0055ae3800781b5cbc.ipv6.abo.wanadoo.fr.
 [2a01:cb00:f48:3e00:55ae:3800:781b:5cbc])
 by smtp.gmail.com with ESMTPSA id
 o29-20020a05600c511d00b003c6b70a4d69sm10970646wms.42.2022.10.17.07.48.42
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 17 Oct 2022 07:48:43 -0700 (PDT)
Mime-Version: 1.0
Date: Mon, 17 Oct 2022 16:48:42 +0200
Message-Id: <CNOA4VLLOBM1.FTSDZQLGKWU5@marty>
Subject: rte-flow: unmatched ingress traffic default action
From: "Robin Jarry" <rjarry@redhat.com>
To: "Ori Kam" <orika@nvidia.com>, "Thomas Monjalon" <thomas@monjalon.net>,
 <dev@dpdk.org>
Cc: "Ilya Maximets" <i.maximets@ovn.org>, "David Marchand"
 <david.marchand@redhat.com>, "Aaron Conole" <aconole@redhat.com>, "Eelco
 Chaudron" <echaudro@redhat.com>, "Kevin Traynor" <ktraynor@redhat.com>
X-Mailer: aerc/0.12.0-98-g00daa226f4c4
X-Mimecast-Spam-Score: 1
X-Mimecast-Originator: redhat.com
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

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-mod=
e

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 =3D rte_flow_create(
        port_id,
        (const struct rte_flow_attr){ .ingress =3D 1 },
        (const struct rte_flow_item []) {
            {
                .type =3D RTE_FLOW_ITEM_TYPE_ETH,
                .spec =3D &(const struct rte_flow_item_eth){
                    .type =3D htons(0x1234),
                },
                .mask =3D &(const struct rte_flow_item_eth){
                    .type =3D htons(0xffff),
                },
            },
            { .type =3D RTE_FLOW_ITEM_TYPE_END },
        },
        (const struct rte_flow_action actions[]){
            {
                .type =3D RTE_FLOW_ACTION_TYPE_QUEUE,
                .conf =3D &(const struct rte_flow_action_queue) {
                    .index =3D 2,
                },
            },
            { .type =3D RTE_FLOW_ACTION_TYPE_END },
        },
        &error,
    );

Can I expect *all* ingress traffic *not* matching ether_type=3D0x1234 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.

--=20
Robin Jarry
Principal Software Engineer
Red Hat