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 9944CA0351; Sun, 9 Jan 2022 13:23:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1CB5A4115C; Sun, 9 Jan 2022 13:23:53 +0100 (CET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2088.outbound.protection.outlook.com [40.107.236.88]) by mails.dpdk.org (Postfix) with ESMTP id 3E8E240042 for ; Sun, 9 Jan 2022 13:23:52 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MADB9HDUawZef6qvyxypYoulH1EXyRnkL4erWc8QzlYUHei02Xb7qrBILtEUAMne5qTkEDwJUFnYUuJ1ct8K57aXt2rEyLQsE0vtzTuN0jdxMNI0rTuk/MF7RPjzmVnOdHpOXD9D+wJvLq59OWW/1JSHdFa8dd7pv7PEwunrUksSWDYDq5T1coN0uhASV1tyxR6Tv2I6mpXXz1wY0yGlggh+d35UeDwoOtv/IvJ5zNKZymxylCEnGeHQsUAXbsiREOWatJjvuocwo8iwBx51Ryz0INuz8B0WzHDq8ExZTAfvx+eHO9HrdSQ0Cis8S2v66KHC8laokOLnd3OdS1SoCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dLxCGZFR97UO/toWt2VbhyAW6jMEMtxpJPhzwXyi2lM=; b=g4AMDu0zPVPW725SyNlyKiuKPjUxuLTlUh3WbEIxpBb4A3yzd/Q3RJ8pwQ8L3rzopL6pe8jQ7GKFJdrurJQxphhTIxMnfwD3NPzxeIXI5QIGtb2wleU/16/cqKNqgUnibM0dNe9OK7xRonBCgfgR4Js89/zIwu9hO3QLJ9DKyBr/jeZjQCjps2BdZ/r+BMbsGa2lVL03Z4WFg0KsssAthedL0Lm/uvYMG4Q0uqSHvoARohfw66cDg+zPqvxJu4hya/01zshAQEEG3fHPympF6WSAaUg30E1z0oDzhzA4Rjev3h/bHTksa9mvPhWUQJemJ/9vGcVZYWpJVDG+2eL51A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dLxCGZFR97UO/toWt2VbhyAW6jMEMtxpJPhzwXyi2lM=; b=LwsppO0/sp23vlgEpJ8u7dgONyYo1W2K/5ko6jdpSaNB9eRm2K7RnB3Mha5SNtq0bBVrj0PR0WhqW8xLKFch4+tv0aR4ZjUgYHbTIEVkLI/+7th83691gIZ6YypyQrOez/+Fk7KisXw8BOBQ8rcKskuR54guR1FyHZlX+HJc74HGDwQmu+EkCNHHLuM1SNsJIjLWxBSMV1qHDNkMqZdncIcAgUL6ThqRpRYtRI1C9NTIpbedcCOJUvxBqmIRoTsCZeGSV+tPHjdf17u5AhQbBCyT+yk5fuzTj3AufJ3FNWQ30sden5uTzMl4Azqj4KQ9i466rhZqDmrVR3ONCWydsg== Received: from MW2PR12MB4666.namprd12.prod.outlook.com (2603:10b6:302:13::22) by MWHPR1201MB2556.namprd12.prod.outlook.com (2603:10b6:300:e3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Sun, 9 Jan 2022 12:23:49 +0000 Received: from MW2PR12MB4666.namprd12.prod.outlook.com ([fe80::78:438a:c6b7:1cc1]) by MW2PR12MB4666.namprd12.prod.outlook.com ([fe80::78:438a:c6b7:1cc1%3]) with mapi id 15.20.4867.011; Sun, 9 Jan 2022 12:23:49 +0000 From: Ori Kam To: Stephen Hemminger , Ivan Malov CC: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "NBU-Contact-Adrien Mazarguil (EXTERNAL)" , "dev@dpdk.org" , Andrew Rybchenko Subject: RE: Understanding Flow API action RSS Thread-Topic: Understanding Flow API action RSS Thread-Index: AQHX/MEw4cm0JPZdFkG5T3Lwla88o6xS12aAgABGoQCAABppAIAAOdQAgAc34BA= Date: Sun, 9 Jan 2022 12:23:49 +0000 Message-ID: References: <76f98055-c517-5185-b79-d16ec5ef5ff@oktetlabs.ru> <4677833.GXAFRqVoOG@thomas> <20220104085442.4e406f2a@hermes.local> <13f1886-d714-7e8-e176-4872a1c8e85@oktetlabs.ru> <20220104135612.4e5c8143@hermes.local> In-Reply-To: <20220104135612.4e5c8143@hermes.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 319a5bc2-c1ab-492e-e4b5-08d9d36ae3f5 x-ms-traffictypediagnostic: MWHPR1201MB2556:EE_ x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eoMnKw9a+6WLZgnGIVbmDFzyxxV5Bd65DAbVtNPJWunSErPVGm3U85kczxRDVj/CfoawxsSZeN6MyevhdK0y5H/yMHTzVQVZuwY5guOFCHVdMLhUub134f99S72Jnwh543Q/GPe0HKuEFw9+0zTn4nNzq3hkRNMK8sgWecpt/cFF6ZOE4ovsFxv7becHYptcVC9htpklB+xXkuaovwiZWpGHKjraiZs+c/tpsuxM97FCVEBbs8M09oCeoSHdPQnCRU3znng8peErfbUWH/Eguu2/i3jDRXnrvX6GfgEV8+70E/C8s2kAIHNXtT5BwzPxsWgVAUu4BRub98Qv7PcaIq7qjKpRmByUN7BG2UORM1o7uTIeuwfBafh7hvBqkoPmpO6LsuXFfseVoro40XXgCOmU2ROiRUWn2BUyxC31pse7mc1EOKYBAnOSmmLBTRbXXQOE8m6K0twU+taHUE1bSvwEM0Q+O6HzV7zry5EcUN5lPBQ8xivi7ks02DNozPqD6l+h0ueuqH8jpvn360ZkW+pyVI9NF4qxymAfU5UN1biMlpHp7a95KPqtATFXgVqRLuV2OfQDPhMmTAao709ePa56kwe+3OB/BYc4oBIbfGSySbW3Txew2yd7k8LVAhoZ20ySeL0+f0FI4nJCqt7ZNB6k7+bAFhYY1ol/69zzSiJKSU0/Uhc8fDxyCWkqAoQRXxEi2AySuTWfL8EMOgDjZg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR12MB4666.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(122000001)(2906002)(66556008)(38100700002)(66446008)(8676002)(55016003)(64756008)(508600001)(8936002)(86362001)(7696005)(83380400001)(26005)(186003)(6506007)(45080400002)(53546011)(66946007)(66476007)(33656002)(9686003)(38070700005)(316002)(71200400001)(52536014)(110136005)(54906003)(4326008)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WfQ31VNkifCVy9unU12iJErvsoiXG5bZUXtpvQuoz3oqFg7wwqFZpDqyE13L?= =?us-ascii?Q?PBxhVVwae9pcA1WvQcVS2DGUZcWE5+D3R2/3Vx4WH2Qs/YyWhwaRhsL+k2GE?= =?us-ascii?Q?EWzzcQak4hNhXfeBCq9dxi7UoRl1d8TRgVLJJhyC5uW7RmfM5Ol8v6IRMgtQ?= =?us-ascii?Q?QzCKUF4WOHtz8wm2HqWxqVvWaU7GRByDxDzOW96mFM2B92mY3NVjiXAEDthE?= =?us-ascii?Q?Y35KjjDpbterfM3hCWGxWmT5We6pfpgXMqzUBTeG46x2pDwfqdjztt+NKO/0?= =?us-ascii?Q?2/VkGUfxaSX9oyZRPs7v3hL+Sl8tmVYfjPhmuoOtmSBen5Gh3mI0Jx3RrD47?= =?us-ascii?Q?31HPnHsB2ulU4SR+uq90BhaOwGKUc3eBV3Td+xhpiyQLeT0CKvKjPM3iTjnD?= =?us-ascii?Q?D+wPDjGTfQM+WqkXnpONuyd+JbT0Jsr/916sr/GyBbWUDZfSJ2kLd6X3xu9q?= =?us-ascii?Q?la7lnAO90XmEY4+0xku8sul6H7sWb71Pnj4VKUC6I3j0Ppt/AebVlU5MFMS9?= =?us-ascii?Q?T1CidaxFXIVhfam7mSL/n9tX27LQ5qaBLFhZkzOxizugZ5S/mHWzZghOUjnF?= =?us-ascii?Q?lp11l8sSNc2oO3x7T+ujDw63ZLsyvwJI5iPHV/5BRxu2fGtMXhWET02veVSv?= =?us-ascii?Q?g4acJjI5tuqvCsIlOJEwWVAMfBKmwHwYTLgnnTIBuLx7Zj70MYrh78OUQnTs?= =?us-ascii?Q?XsKwXwevoifNmhmSNic2oGZE7gyk8NeGj0cb5WctbQZz7pqaFp1SdFY9zI4g?= =?us-ascii?Q?JtaHA3P0/WBlcOz2kkeEGri3AyCp5fHdpj0s478gSt/r+JaIT1eOmHFWC6vW?= =?us-ascii?Q?QFRcN2aQixrYfcF35YOBw3VrkFBeuQsI6goGPKJFs0qLh5BiEgGEL+svGOw1?= =?us-ascii?Q?JUP7+irDlPHDz+anRyR80J43f5tnO3oWYKN0zjq6CtqoExRIIgSDdfHL3FBw?= =?us-ascii?Q?DSmVBTx9LROUnVHCAWiajt7mBMp0DI1aSVdzatUNsVW150+3oDxzChP+kEbJ?= =?us-ascii?Q?Jf+mCokD6tbSDDitrPl1F3RM0+oWymR+6WcbVOjcwK5RhmrNr3zUGRSWJQj7?= =?us-ascii?Q?e7enBTSHh6GUBvsrp7b5jKpYGMmnRTi8yrFQe0pMGRGdU+BH6tIqQQPyKnLs?= =?us-ascii?Q?YYGOW5IpPxOkjEx/Qc+kLNjBkoPk3zXcgS0ScHQ4AhU+F2BkBLHbfGBtlfbz?= =?us-ascii?Q?6t6PVNRGk30fbGT3qLXdhAYNX9jnLuoOHeYTeZPcv5fRlPuxUHHnqDWBAuOx?= =?us-ascii?Q?bJcAz0PKs6MDg4tVOqVxM6l7RbtMC+aYdEA2oc9BnaspOizhVL6MK3rJjUF3?= =?us-ascii?Q?RlYyno+bSOy/PMlK4+UJr6TM3LxZo0XlqiFWe65+VDXOAzWkKdd40iMOXT0K?= =?us-ascii?Q?7KWu9INeLat0vYrB8VL0x1tnTboazolF8RtlZUOfcsKGh2n99ycCVPI8Vgl2?= =?us-ascii?Q?oRcQERZEzNwdwguoQJxNQFL/8W8Ebdtq5dEY8tLWtfWc1gnf6ZsHMZlNMj3C?= =?us-ascii?Q?zfh5m2RWaiO5XJCx6JvyLgNn3+moBc+1GZYSOzmdPWxsfJ4XA8tS6XFanyCI?= =?us-ascii?Q?M1Qj84mn7CLGKPdjpQksP0rZJM1CS9F0ihhk0DMvlt8NlxA6M8CqMKuu8vND?= =?us-ascii?Q?yQ=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR12MB4666.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 319a5bc2-c1ab-492e-e4b5-08d9d36ae3f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2022 12:23:49.3547 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ncFisRyDgNtNbdS4xmcyU6cuWWmJhCQIW9+Tv1sap75FN+GvWYTeJL4+bsBngCL/gT/JcQ4Noo5qO/CqW9xhOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB2556 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 Stephen and Ivan > -----Original Message----- > From: Stephen Hemminger > Sent: Tuesday, January 4, 2022 11:56 PM > Subject: Re: Understanding Flow API action RSS >=20 > On Tue, 4 Jan 2022 21:29:14 +0300 (MSK) > Ivan Malov wrote: >=20 > > Hi Stephen, > > > > On Tue, 4 Jan 2022, Stephen Hemminger wrote: > > > > > On Tue, 04 Jan 2022 13:41:55 +0100 > > > Thomas Monjalon 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, 'que= ue' is > > >>> to provide "Queue indices to use". But it is unclear whether the or= der 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 tab= le. > > > > 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. > > >From API in RSS the queues are simply the queue ID, order doesn't matter, Duplicating the queue may affect the the spread based on the HW/PMD. In common case each queue should appear only once and the PMD may duplicate entries to get the best performance. > > > > > > rx queue =3D RSS_indirection_table[ RSS_hash_value % RSS_indirecti= on_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 o= f 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 s= ize > > for this action? Can it select an arbitrary value? Or should it stick w= ith > > 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. > > Just like you said RSS simply spread the traffic to the given queues. If application wants to send traffic to some queue it should use the queue = action. > > 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? >=20 > You are right this area is completely undocumented. Personally would real= ly like > it if rte_flow had a reference software implementation and all the HW ven= dors > had to make sure their HW matched the SW reference version. But this a ca= se > where the funding is all on the HW side, and no one has time or resources > to do a complete SW version.. >=20 > 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/st= op > queues and use rte_flow to reach them. >=20 > But it doesn't appear the HW follows that model. >=20 >=20 > > >>> When the user selects 'RTE_ETH_HASH_FUNCTION_DEFAULT' in action RSS= , does > > >>> that allow the PMD to configure an arbitrary, non-Toeplitz hash alg= orithm? > > > > > > No the default is always Toeplitz. This goes back to the original de= finition > > > 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. Feel free to add/suggest what example are missing. > > > > Thanks, > > Ivan M. Best, Ori