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 BBCEDA0C47; Thu, 4 Nov 2021 16:52:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3E9CF41223; Thu, 4 Nov 2021 16:52:19 +0100 (CET) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60123.outbound.protection.outlook.com [40.107.6.123]) by mails.dpdk.org (Postfix) with ESMTP id CE16D411C9 for ; Thu, 4 Nov 2021 16:52:17 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JWO/RWfhRMcYAHyEu/j2z0FgZ9BSoAdBErWnuh8YFUuQhueDCkSQPwtdSu79NiLblzJ3BNSBZy2weRGTpoz/zZkBNcOmGBFOVstljTiEhWAFEignPUbeC2SPMZMZiT5kh9cCUj/INV5j+bGlId1RR933HG/hDBhKL1pm+lmfyjNQp7+UyEL2T4W8CUGacuahoSZlA0ddGkIl7GreJM+d8tUOPgpGy4zkonKpTAQgUbd0Qx291kQpxU+fAGofQ5EsIKgCOQO4hU3ZlxmR8Ms3QwAWn4UUMbWKTij/oy3ppLwP1/zwdONQAPJdOms2JoZll54exYm38tgSUstm266slg== 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=T2lwkZ2PkUbOBu1Z/g6c97mdTIZrMunpTE5XPtOdkUg=; b=OnbxSeNB7ej+9O9xzHjrwSlOTXn6rpAAjIRt+cC1xDJJhATotqjOTJfkeBQ2YG2sy1jO6H/CkSbi57tCXDR7Pch2pPMrl5VkEb7u5wExMVSuUcVWx44qDJEEH1FOVdNmSSYymxKdu3ZOA7XhnRD0kIC+i1KACcuRX3xWMLBG5AdrfKzJ8QuyEzJrGcdkD4Pae/1o/m9c10egDneBDr4LhH0AHiwd5TZIW4A1zvCjcrPWU/gMfGL8Tl+O1PU3B8d1A+2/7fKk+BdqAug3faFKVyPncwKoXoY4MmTuL2rxHK+gFHYk6iDBPnI2W2T7w/45ItRhd9C+T8cVMKS3du09og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T2lwkZ2PkUbOBu1Z/g6c97mdTIZrMunpTE5XPtOdkUg=; b=FtbuwqzpJKiekhAekctuLg974Y52DChCjyKZK+msMb0WfoylUzBA4uNYNjJ0lE/3coHGfbJJ/WLRCdDvgD5emgA5kRvJmPKdBkBioO0EBztEMNGWSgR3F+CRjf0WhWFe1a8QjOC+bb4m/Di7VhuMfLGLf8v1NyPSfyH5MFkHbnE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uclouvain.be; Received: from AM9PR03MB7632.eurprd03.prod.outlook.com (2603:10a6:20b:413::19) by AM9PR03MB7560.eurprd03.prod.outlook.com (2603:10a6:20b:417::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.11; Thu, 4 Nov 2021 15:52:16 +0000 Received: from AM9PR03MB7632.eurprd03.prod.outlook.com ([fe80::3031:cf2d:5c9f:65e]) by AM9PR03MB7632.eurprd03.prod.outlook.com ([fe80::3031:cf2d:5c9f:65e%6]) with mapi id 15.20.4669.011; Thu, 4 Nov 2021 15:52:16 +0000 Message-ID: <27dad5b3-afd5-fed3-41b9-4b02c55aa994@uclouvain.be> Date: Thu, 4 Nov 2021 16:52:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 From: Tom Barbette To: Xueming Li , dev@dpdk.org, Zhang Yuying , Li Xiaoyun Cc: Jerin Jacob , Ferruh Yigit , Andrew Rybchenko , Viacheslav Ovsiienko , Thomas Monjalon , Lior Margalit , Ananyev Konstantin , Ajit Khaparde References: <20210727034204.20649-1-xuemingl@nvidia.com> <20211021104142.2649060-1-xuemingl@nvidia.com> Content-Language: fr In-Reply-To: <20211021104142.2649060-1-xuemingl@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR04CA0038.eurprd04.prod.outlook.com (2603:10a6:208:1::15) To AM9PR03MB7632.eurprd03.prod.outlook.com (2603:10a6:20b:413::19) MIME-Version: 1.0 Received: from [192.168.1.144] (62.197.82.40) by AM0PR04CA0038.eurprd04.prod.outlook.com (2603:10a6:208:1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10 via Frontend Transport; Thu, 4 Nov 2021 15:52:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9ac15a5c-bc85-45b5-e202-08d99fab1312 X-MS-TrafficTypeDiagnostic: AM9PR03MB7560: 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: vvVZycilSweF8P9Qjj1ET1oYWcMTrYv3lG9AgM2Vs4vsrrktNPn7Chhoi6Enr2YMB+CuqwapCWOp/ZSGVg5Ju7T9vkYUQaXyhdDyJSpVzm/97AKNQ3qoAgeYk7oo90rYYrRUxm7UBieqsGTrHrfBBkMOc9AV9QVtu8eCnPnY+CG/D6TL7v2c/Dm7W8BEN4rJ1WzNepTs0q8bxtoUn004SNQaa+hEJBrrlqjEBF2cO46HJ/hGS1JwB5OKRvKBmlKbVu0hHvUgaKs+6PY3Tu4ybj1ovyK5r04ze1SjML8q31AV/lxJ5qlfK+PiMFMK0EZOHpebXkbQUCV1wbilx4XwzKAYfadDjZVKk5Iuryw24W0ku4la8I3YV1956vwu3GJg3bRHaMwSz+cvqdNfbQOJHQrpnn7ZjTyR2ZfhfNE9w/EI0MyB0LfC71cKbOBKbX1gkbkdG+D7U7jYfr6ocHhJh8IhJF1U3Vz3ldgaX+T/Vn2eAp4Ovws6YjH6B5cgfFm6ZVkVgue6GwMeNleil/DQHYRbD6+cLuvq1nU8Viuviqm4c4cWRGWY8do8aKDs9QfChziqcv2pKaDyUForU25OmUoZOy921/LsTizVxI5Qyzlv/TrPz2I18DJZCKt/vgGJOvrLYbc/h/AQ8LBqOBLomTMXKCFYQSojXl+treR0RFnJ1AfQ7iB2bp9em41y6TuM+NmidcpG1gLXVrfNaN3XvffKV9rDIOvmpCxOyKJsJHw67i0KxnEbUV0sP+K5SIljIqMEEo8KWVMRKWV4hlXLuN4nHvd+m0QCXYo0Eu0EOlV658E/R2kRsrahVttWrSE7yKAHyqS70eBPcIlRYt3ViQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR03MB7632.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(36756003)(110136005)(52116002)(786003)(316002)(6486002)(186003)(26005)(8936002)(16576012)(966005)(7416002)(8676002)(38350700002)(508600001)(54906003)(38100700002)(66574015)(31696002)(956004)(44832011)(2906002)(86362001)(83380400001)(5660300002)(4326008)(2616005)(31686004)(66946007)(66556008)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dCtGWlpvT1dYME5lY1NFV0FzUGpDYXdwanZGc3AyQkJBUjJLNTNOWUFUcnRw?= =?utf-8?B?cGJlcnU3anY4aTl5eWN4T3dkbnBsTHp6c0dHVUorUUFNRzRvV2kvUXltYjZO?= =?utf-8?B?WUR4MHluQVVpSUtSV2NMRGFNNmxyWWJOcVEwZGFOd3IwNEJyTHQyeWNpN2pz?= =?utf-8?B?cFRlQ0RuNzNXSWRhRUdrUFVjbTdqVGFkd3lldTQyM3hVemVDRXV4Z1dtallj?= =?utf-8?B?dHJkb1ZQb3VwRWl2WWl1Yk44RlFMNlhpVWU1eU5QQkJLODRnZVdVdlBkcHFF?= =?utf-8?B?Q0tXcmx2QXBaS0RUTFlqYmV0WU1uMUVqVXdwY0o3RG5Ic2V4OHpzWWxzSzB2?= =?utf-8?B?ZVhRVldLWmZzUnJ6YVYxOUNXUmMvY0pBT2FMVTU4VXZ5QkpvUDdrbW5icHht?= =?utf-8?B?NytDVUJvNkg5WExRTWo0eHBlN29mMXJITFVGUDY5bmdXNGhPOFB0RlByWXhv?= =?utf-8?B?QklIaTNITHQwMVhiNE5jRzE4dE12aGl2dW02ZGZITUYxR212NHpTQkNTZDlO?= =?utf-8?B?WW9WZnB3bFc5dG5mSHgyMDJuc3A4ZkgzVnFaZUw2L2phT1lDN3V5anFoOTRZ?= =?utf-8?B?T0hUVzJReWZxNm9Ub3hvaHJvSVRVdUxzUVp2eUViRENGQW1INFh5OWlwTWdY?= =?utf-8?B?T0pxM3gxcmVVd012OTF1eDRTdjd5aWppNkIvWlM1cTNuNnNmT1lPOWk2a2NR?= =?utf-8?B?Sy83RjdEbEt0U0V5RGlKdTRubUtvR04rdExSamVtcWFxNjN5S1h1dXdyRHpu?= =?utf-8?B?RWt6SUdCYVB3UW5lZVVSQXBrejl5L28rT1hDYUJ2c0t0QVVGRUMwU1RTMUZZ?= =?utf-8?B?RUlUUUp2Ym5hZXNpOHJ5TzFEYXh1Nk9UNExxRmtZaVVCN3ZlM3B6c0ZZMkE4?= =?utf-8?B?bVY3MnJMUWx5d1AwbVkrUzFIUVFMRnFqeXh6YlFrdDhqOEJHRFVvUnBMZm1w?= =?utf-8?B?eTdhMm03QjRtMzRZWWxwRlVmNmUwa1hKTzJLWEttdmVQb1hGdVpibHVGMDRQ?= =?utf-8?B?VDBkTnhTTDlQWTR6Q0dSL3k2Ymo4QWF5cWVScEo3Vk40bWk3eXg2bE9qNVgz?= =?utf-8?B?VFgvR1ErYzExdElXM3pJdGtlVEpzM05ER1QyM1o4VUNIbFVXcjE3OC9DS1ZI?= =?utf-8?B?K3I1emd6NWxzV0ZYdSsvTVA3eWZVbGtSNWJyOFlWcVZtYmpmM0Q5SDlocm5H?= =?utf-8?B?bzNOREZXUXNoQUNnSW9pUjJubHBZU1c5UVo4Q3h4TlZsbTZpUTZRWk9sQmVX?= =?utf-8?B?Y0VjWDBzUmNGL1dFNi9lY3M3cktEb3I2K1lyL1RNSjB2aXBoNmI3WE9NeFNu?= =?utf-8?B?c1hRNzdQVkpyUmlSRzRMVWczZFh6ZlNXbFJlem9YSVFVUVpUVGZIR01za002?= =?utf-8?B?MFV1VXpZbGJBVUF2WTU2ZTZMNlkrSThVK0ZoN2R4QTFKenAyLzZiR3NYdTlZ?= =?utf-8?B?Mzk4d2oxMmlyUUZ6bkh1TERKK1pQbnA3VExhQVZoWGhiZ2h6eENZNUptUEEr?= =?utf-8?B?RW8yY09ReTByN2hxQytZQ09DSi9ER2VSSkI2dGRBYmVFZ09oT0l6MkxML0Rt?= =?utf-8?B?cTFRSFNrSWh4VjB1bTcvR0QxSHZ2N2Fmd3VSTzBHOGVvaldUTmk3c2pIb0FL?= =?utf-8?B?bG1Za29vVWlYbDg5bUdqeElnNjFuUEtxbFVXZDNPZS9pakFZZ0dQb0h2Slln?= =?utf-8?B?S29WUm5tYjEyd2NMYTBUdnlzNW9FZU1NMTJnT1o1TDc0RldpQzl0dExxNU9u?= =?utf-8?B?MTFsODM4cnlHdTQ2STFhOXdZNllrcUpiRG9xdUppWGx1YisyR2pBZmJ3M01r?= =?utf-8?B?N0NkNTZMTEdSTmpzelZMeDFpMlpDeng5ckQ1bkhMSUJFMm9PVUh2akFqTnQ4?= =?utf-8?B?VGdXRjA3WG5oY3lZclordDFoSUt2dmdqOWloMTNNRlVteHhaV0VFa29KT1Jk?= =?utf-8?B?QmdhVFdaelhNaEFhVUZqN0xabmFHUlFVamx3Zk1IREU5cDcvYnZWSVNRemlO?= =?utf-8?B?UGYwb0xyem1WRE9SRm95Yi9NeFVqcE5nbjFpTGZWUFZTdDZQVnZxV1NPRXBR?= =?utf-8?B?eUZIZHFTc0x4THQ2cVZZTXVtNGNhMFNzSHp3alFDRytMNnlOeGwwQ2Q1ckp4?= =?utf-8?B?cHRUcldCT1FXTXZQSWdYWnNiK1RFTUN1aDQvNEpzaWVTOWpaaHluYWZydzM3?= =?utf-8?B?ak84ckc1YWRtOXFFMmRwRDBtbC9LR3BzeC8xZlVoUzBmYXQ2Y1p0VnVySU1h?= =?utf-8?B?djRrTzFYQklqUG1HUW8xbFRVSVlRPT0=?= X-OriginatorOrg: uclouvain.be X-MS-Exchange-CrossTenant-Network-Message-Id: 9ac15a5c-bc85-45b5-e202-08d99fab1312 X-MS-Exchange-CrossTenant-AuthSource: AM9PR03MB7632.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Nov 2021 15:52:16.0064 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: OPeAuMphfg8Dn7WQvrC0+HaqBxJT8kiSaWeboeTNzkmlHusPSBN25KMq4HncZFheaD2TGNZaHumda8/HOCmHL3rawVde054CXsuXFKfissM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR03MB7560 Subject: Re: [dpdk-dev] [PATCH v13 0/7] ethdev: introduce shared Rx queue 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 Sender: "dev" Le 21-10-21 à 12:41, Xueming Li a écrit : > In current DPDK framework, all Rx queues is pre-loaded with mbufs for > incoming packets. When number of representors scale out in a switch > domain, the memory consumption became significant. Further more, > polling all ports leads to high cache miss, high latency and low > throughputs. > > This patch introduces shared Rx queue. PF and representors in same > Rx domain and switch domain could share Rx queue set by specifying > non-zero share group value in Rx queue configuration. > > All ports that share Rx queue actually shares hardware descriptor > queue and feed all Rx queues with one descriptor supply, memory is saved. > > Polling any queue using same shared Rx queue receives packets from all > member ports. Source port is identified by mbuf->port. > > Multiple groups is supported by group ID. Port queue number in a shared > group should be identical. Queue index is 1:1 mapped in shared group. > An example of two share groups: > Group1, 4 shared Rx queues per member port: PF, repr0, repr1 > Group2, 2 shared Rx queues per member port: repr2, repr3, ... repr127 > Poll first port for each group: > core port queue > 0 0 0 > 1 0 1 > 2 0 2 > 3 0 3 > 4 2 0 > 5 2 1 > > Shared Rx queue must be polled on single thread or core. If both PF0 and > representor0 joined same share group, can't poll pf0rxq0 on core1 and > rep0rxq0 on core2. Actually, polling one port within share group is > sufficient since polling any port in group will return packets for any > port in group. > > There was some discussion to aggregate member ports in same group into a > dummy port, several ways to achieve it. Since it optional, need to collect > more feedback and requirement from user, make better decision later. > > v1: > - initial version > v2: > - add testpmd patches > v3: > - change common forwarding api to macro for performance, thanks Jerin. > - save global variable accessed in forwarding to flowstream to minimize > cache miss > - combined patches for each forwarding engine > - support multiple groups in testpmd "--share-rxq" parameter > - new api to aggregate shared rxq group > v4: > - spelling fixes > - remove shared-rxq support for all forwarding engines > - add dedicate shared-rxq forwarding engine > v5: > - fix grammars > - remove aggregate api and leave it for later discussion > - add release notes > - add deployment example > v6: > - replace RxQ offload flag with device offload capability flag > - add Rx domain > - RxQ is shared when share group > 0 > - update testpmd accordingly > v7: > - fix testpmd share group id allocation > - change rx_domain to 16bits > v8: > - add new patch for testpmd to show device Rx domain ID and capability > - new share_qid in RxQ configuration > v9: > - fix some spelling > v10: > - add device capability name api > v11: > - remove macro from device capability name list > v12: > - rephrase > - in forwarding core check, add global flag and RxQ enabled check > v13: > - update imports of new forwarding engine > - rephrase > > Xueming Li (7): > ethdev: introduce shared Rx queue > ethdev: get device capability name as string > app/testpmd: dump device capability and Rx domain info > app/testpmd: new parameter to enable shared Rx queue > app/testpmd: dump port info for shared Rx queue > app/testpmd: force shared Rx queue polled on same core > app/testpmd: add forwarding engine for shared Rx queue > > app/test-pmd/config.c | 141 +++++++++++++++++- > app/test-pmd/meson.build | 1 + > app/test-pmd/parameters.c | 13 ++ > app/test-pmd/shared_rxq_fwd.c | 115 ++++++++++++++ > app/test-pmd/testpmd.c | 26 +++- > app/test-pmd/testpmd.h | 5 + > app/test-pmd/util.c | 3 + > doc/guides/nics/features.rst | 13 ++ > doc/guides/nics/features/default.ini | 1 + > .../prog_guide/switch_representation.rst | 11 ++ > doc/guides/rel_notes/release_21_11.rst | 6 + > doc/guides/testpmd_app_ug/run_app.rst | 9 ++ > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +- > lib/ethdev/rte_ethdev.c | 33 ++++ > lib/ethdev/rte_ethdev.h | 38 +++++ > lib/ethdev/version.map | 1 + > 16 files changed, 415 insertions(+), 6 deletions(-) > create mode 100644 app/test-pmd/shared_rxq_fwd.c Hi all, Sorry to jump in this late but I think this solves only a consequence of another "problem", the fact the mbuf descriptor is coupled with the buffer. And you might want to consider another approach that does not require API change. The problem (partially solved by this patch) is that you'll "touch" many descriptors (the rte_mbuf itself) if you have many queues, or even a few queues but with quite large rings. Those descriptors, will all be likely out of cache when you access them. However, as we demonstrated with mlx5 (see https://packetmill.io/) you can build a descriptor from scratch out of the NIC hw ring that points to the underlying buffer in an indirect way. This descriptor can be taken out of the thread-local buffer pool. You'll actualy keep as much mbufs descriptors in-flight as your burst size. Which probably even defeats what this patch can do, as you can actually use only 32 descriptors per thread for any number of queues of any size. What that solution does not solve is the need to poll many different queues. I think that is orthogonal, with the NICs getting smarter we're going to have many rules sending traffic to per-application, per-priority queues anyway. Maybe even per-microflows. To solve this we would need a kind of queue bitmask set in hw to indicate which queue to poll instead of trying all of them. Maybe this can be done through a FW update? It's a feature we'll want in the future in any cases. The shared RX queue is surely an easy fix for the polling itself, but one problem of the shared RX queue is that it will lead to scattered batches. We'll get batches of packets from all ports that will surely take different code path for anything above forwarding, breaking the benefit of batching (this can also lead up to 50% of performance penalty due to interleaved burst, see https://people.kth.se/~dejanko/documents/publications/ordermatters-nsdi22.pdf). Cheers, Tom