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 4D729A034C; Tue, 4 Jan 2022 22:56:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C6AF240042; Tue, 4 Jan 2022 22:56:17 +0100 (CET) Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by mails.dpdk.org (Postfix) with ESMTP id B275A40040 for <dev@dpdk.org>; Tue, 4 Jan 2022 22:56:16 +0100 (CET) Received: by mail-pj1-f52.google.com with SMTP id n30-20020a17090a5aa100b001b2b6509685so4504363pji.3 for <dev@dpdk.org>; Tue, 04 Jan 2022 13:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=504yk0aFIBUOe2XnlLRbC6VNqsa2ZRHwEcHPF1YZq7o=; b=CcyRLunu6a88+Quq/v5C/uNC+0t4HKM6ULR+59oynznsPBR1JYckReo4MeqyTsv+1+ 6SELDewGfyjherG4t2ueqb20L6E/Cjk9vg9oCWxHx8QX18sBZKzGo4QmS5D5E21kuIJf g8ERsQier1g8Kytl+dTjb6t4bpmP2kd4/OD54fz9LE7Jv4sGctaJHfBYcB1OsJ/aIaQT Fbsal0GjjMmFpnR8toVmi1ip/JOUYB44udFqMMQ/0rnNmEcbvdqWqS9wSkwTABbrN6bP QUX8uxgQUmahltdKYUZl4CArmsKJ5wQEfsNBQdNF9JCWkBzRfUBg1PlAYtZGshbWDjE1 6RQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=504yk0aFIBUOe2XnlLRbC6VNqsa2ZRHwEcHPF1YZq7o=; b=sXEHsTc1h42g4W0hnketwMkFR1F7VU4Hu/yg1DSqsvfAUDhI4tWBpaaaiexoqs56Sr 8O0WUeS/9xEbJpyjKby4ElIUvHgipCejKbWsEXVQ5XjWkP7REQiqO87PB3BK9CXXkFgG Bb4BNXWAGNizyuzZR9I2txOwThEt76H7YFWbNvoo5SBsWJwYx7B6pyOLZ1rCfnGt/l43 CfP7C5iAwC2BsNlFR1FqvJK+cN/8kW9/RnUvyLX3ZUoB0Rr9/BVF1hLr9NtD7z2EZWNE cZvKry9Mvh41bF4LtHK7wpGU/ET/RYPQEl0Te5ixEh/nkRNbhXMX9DuUn+NgEnQOZTCL BPwA== X-Gm-Message-State: AOAM532JC0Y/sRofTb1CfDNHleXvT/fHka2zmk0axo3vPvS0w+QI8GUg 6Rw0piPUO8Ym2YNOPosfzPbu9w== X-Google-Smtp-Source: ABdhPJyR9l9jJgStBdFN+pTPEo/KfrKUx25SrYXoVpoJCG7eL/3LvzaZVGfJS0Di5JQ9OsRjUcxKpg== X-Received: by 2002:a17:90b:1d10:: with SMTP id on16mr468035pjb.196.1641333375638; Tue, 04 Jan 2022 13:56:15 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id k8sm262582pjs.53.2022.01.04.13.56.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 13:56:15 -0800 (PST) Date: Tue, 4 Jan 2022 13:56:12 -0800 From: Stephen Hemminger <stephen@networkplumber.org> To: Ivan Malov <ivan.malov@oktetlabs.ru> Cc: Thomas Monjalon <thomas@monjalon.net>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, dev@dpdk.org, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, orika@nvidia.com Subject: Re: Understanding Flow API action RSS Message-ID: <20220104135612.4e5c8143@hermes.local> In-Reply-To: <13f1886-d714-7e8-e176-4872a1c8e85@oktetlabs.ru> References: <76f98055-c517-5185-b79-d16ec5ef5ff@oktetlabs.ru> <4677833.GXAFRqVoOG@thomas> <20220104085442.4e406f2a@hermes.local> <13f1886-d714-7e8-e176-4872a1c8e85@oktetlabs.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 4 Jan 2022 21:29:14 +0300 (MSK) Ivan Malov <ivan.malov@oktetlabs.ru> wrote: > Hi Stephen, > > On Tue, 4 Jan 2022, Stephen Hemminger wrote: > > > On Tue, 04 Jan 2022 13:41:55 +0100 > > Thomas Monjalon <thomas@monjalon.net> wrote: > > > >> +Cc Ori Kam, rte_flow maintainer > >> > >> 29/12/2021 15:34, Ivan Malov: > >>> Hi all, > >>> > >>> In 'rte_flow.h', there is 'struct rte_flow_action_rss'. In it, 'queue' is > >>> to provide "Queue indices to use". But it is unclear whether the order of > >>> elements is meaningful or not. Does that matter? Can queue indices repeat? > > > > The order probably doesn't matter, it is like the RSS indirection table. > > Sorry, but RSS indirection table (RETA) assumes some structure. In it, > queue indices can repeat, and the order is meaningful. In DPDK, RETA > may comprise multiple "groups", each one comprising 64 entries. > > This 'queue' array in flow action RSS does not stick with the same > terminology, it does not reuse the definition of RETA "group", etc. > Just "queue indices to use". No definition of order, no structure. > > The API contract is not clear. Neither to users, nor to PMDs. > > > > > rx queue = RSS_indirection_table[ RSS_hash_value % RSS_indirection_table_size ] > > > > So you could play with multiple queues matching same hash value, but that > > would be uncommon. > > > >>> An ethdev may have "global" RSS setting with an indirection table of some > >>> fixed size (say, 512). In what comes to flow rules, does that size matter? > > > > Global RSS is only used if the incoming packet does not match any rte_flow > > action. If there is a a RTE_FLOW_ACTION_TYPE_QUEUE or RTE_FLOW_ACTION_TYPE_RSS > > these take precedence. > > Yes, I know all of that. The question is how does the PMD select RETA size > for this action? Can it select an arbitrary value? Or should it stick with > the "global" one (eg. 512)? How does the user know the table size? > > If the user simply wants to spread traffic across the given queues, > the effective table size is a don't care to them, and the existing > API contract is fine. But if the user expects that certain packets > hit some precise queues, they need to know the table size for that. > > So, the question is whether the users should or should not build > any expectations of the effective table size and, if they should, > are they supposed to use the "global" table size for that? You are right this area is completely undocumented. Personally would really like it if rte_flow had a reference software implementation and all the HW vendors had to make sure their HW matched the SW reference version. But this a case where the funding is all on the HW side, and no one has time or resources to do a complete SW version.. A sane implementation would configure RSS indirection as across all rx queues that were available when the device was started; ie all queues that did not have deferred start set. Then the application would start/stop queues and use rte_flow to reach them. But it doesn't appear the HW follows that model. > >>> When the user selects 'RTE_ETH_HASH_FUNCTION_DEFAULT' in action RSS, does > >>> that allow the PMD to configure an arbitrary, non-Toeplitz hash algorithm? > > > > No the default is always Toeplitz. This goes back to the original definition > > of RSS which is in Microsoft NDIS and uses Toeplitz. > > Then why have a dedicated enum named TOEPLITZ? Also, once again, the > documentation should be more specific to say which algorithm exactly > this DEFAULT choice provides. Otherwise, it is very vague. > > > > > DPDK should have more examples of using rte_flow, I have some samples > > but they aren't that useful. > > > > I could not agree more. > > Thanks, > Ivan M.