From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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 ; 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: Subject: rte-flow: unmatched ingress traffic default action From: "Robin Jarry" To: "Ori Kam" , "Thomas Monjalon" , Cc: "Ilya Maximets" , "David Marchand" , "Aaron Conole" , "Eelco Chaudron" , "Kevin Traynor" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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