Message ID | 20240419031226.1191069-1-chaoyong.he@corigine.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 936ED43EA9; Fri, 19 Apr 2024 05:12:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1ACA64027D; Fri, 19 Apr 2024 05:12:54 +0200 (CEST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2114.outbound.protection.outlook.com [40.107.212.114]) by mails.dpdk.org (Postfix) with ESMTP id 18FB540273 for <dev@dpdk.org>; Fri, 19 Apr 2024 05:12:52 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2+ykW4A/rsTiFLpuCcA/yR6l4UgbZ7Tg57AtgxTOt5Z0ni5+IbMLRQqSmwCe77onK3j4jQRBo4+n+2Q4VPETDHWylhznx+qgj8SNv8v77/LEzGflEfMqWVrCfnZCwcFgd8J7jNtciPBpVXaupAk/lK/Q/SaAexODARR8oWBU8Awh7EvbuoYd3DIsUexm0a3Xg4bHV62VJMVXrSuUY+4qIR7InlTFOl4RrdebkKsaHaINhH5E/Ah5L/tQSbNoaOMApJy+ceMWkZzPc8uVLp0egsZJ461/vnU1wZDlP43HiQnrEUp6sIvuI9TEZpRA9/LMtfxnm45pYqJPSCN/dA4Cg== 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=oYeAcfzpOlNNMfsTAdlDJBJylF85TUyn6yGYcxqkFlw=; b=WkFv1x8YjWKdRi4yZStRBUr/a6zScSJVLGiZahdJ3E9lDgIhL6X6rTxJIkVjOhR7z7U7f0Hbw2fpr2xX3Kxf5y0Kwv59GQzJa67Zn4skMQrh8q5jVkS29P9Q7gfzDW9vmyfooXsUtHTRjnzhJ2SnmckLeSWNLMzYb78chO9u61WzRTAyUxxaeBEuUTJ4BQnB09NW0CNg//Mhthnf4ZZwUqtJA/SXIZsoKQt8pE5mmq5/2ma3WL2xmqjQPdUMa5f8FSRz4iY4hRIab6lqTSonVb76gvOr4sW7FRP3aQHXdvz4oAHKh9hC/F3eMDh7mUkjEh9HGx+m7I8G5bhg0e5jfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=corigine.com; dmarc=pass action=none header.from=corigine.com; dkim=pass header.d=corigine.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=corigine.onmicrosoft.com; s=selector2-corigine-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oYeAcfzpOlNNMfsTAdlDJBJylF85TUyn6yGYcxqkFlw=; b=tC2Pa/4p2zpyjVV8WHfwe+gU5La/f6vMmlnMwNANFcR6X99lE5Ifxi/Ei55PCBmhzOW+bEfX34ZVwFb1A5i1Qg9T2oJPqAsKcNr3/GITqk7S7js5sFaqC1GMmDmRrc0OuGVJbfrrHZPwY3vcC0pYowmU6sf0sTrb4uh9HuHG424= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=corigine.com; Received: from SJ0PR13MB5545.namprd13.prod.outlook.com (2603:10b6:a03:424::5) by IA2PR13MB6587.namprd13.prod.outlook.com (2603:10b6:208:4ab::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7472.43; Fri, 19 Apr 2024 03:12:48 +0000 Received: from SJ0PR13MB5545.namprd13.prod.outlook.com ([fe80::ec12:7411:559a:850e]) by SJ0PR13MB5545.namprd13.prod.outlook.com ([fe80::ec12:7411:559a:850e%5]) with mapi id 15.20.7472.042; Fri, 19 Apr 2024 03:12:48 +0000 From: Chaoyong He <chaoyong.he@corigine.com> To: dev@dpdk.org Cc: oss-drivers@corigine.com, Chaoyong He <chaoyong.he@corigine.com> Subject: [PATCH 0/8] refactor logic to support secondary process Date: Fri, 19 Apr 2024 11:12:18 +0800 Message-Id: <20240419031226.1191069-1-chaoyong.he@corigine.com> X-Mailer: git-send-email 2.39.1 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SI2PR01CA0044.apcprd01.prod.exchangelabs.com (2603:1096:4:193::8) To SJ0PR13MB5545.namprd13.prod.outlook.com (2603:10b6:a03:424::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ0PR13MB5545:EE_|IA2PR13MB6587:EE_ X-MS-Office365-Filtering-Correlation-Id: 0d8a0a5e-4f6a-47b0-de15-08dc601e9704 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6cS1n1EvyAF349R9gmhHRSjK4OhXnYFMHkKYp5lOaSakwOCPlRRCWhfFaFx0szziqdyY/ctuRcnKaF7CEG/Boonk+5GHHzFMpxq/PZDFaizTAO6TQTAB5NgtWe6wnrfZKlwdADw0GN1mwpY8vK8v5WuKerYyPMzPFu8wr/80I+JwKB+RICSDBvbQyb5XH31b2p4sP5MYSl3ujBcEuT/H192L61BnOiVSJJ7jeRM9ETnhWpOuO5zn/Qoxockiqe4o97OBCWl9xd9QVtQdA09Rs4TzB+D2Po8eL22/GvD2/to+laZ3fVO6UaWkopZyRsEV5xr7Dq88fVqnb/5xN7HHLtltokFsQwObnYvpJgl55gJcOeGmuNJ8idSH0dwDo1fQKvYTyT8JocaKCKw14Idq1MPyKx3tW4uKd1hAjP47xVdkGBN750uBr/P1UdK6VgmojZm5oW/WtHgCYvA4A38UfD/KcTDOxoxlv8dhThLLcp+0D82HYAVd26gDoPqhwziu94PGLOaPxir8Sga/xwNl6uA8103zQ86wFnZdWTGMadALxnqGf03gMSG8ChylmbmuVSS9MN7VveV+Iw3GdT3nshY1uklI5uX2Nj4ov2e8mcHYUNwk7fJLW6cjejixHU0djh1iNTr48dtWA0QAYrL8IPENyZvjq9nEhiMbgCEImEFqdunSNQmNxKMMi/zu/U+gtmG9OX0AnNI91iC0yAKtC8RmyDRu0uYbft5wkZ579zOe0mILbR++mCmE8/xXSMk7AAeYh9AAIgy/FniJHphK2hsDJy2McTgETLWK4tUAVY6TylWDyYu2mUAc/GTWtHiCSjIjy4mrz8WnBwULIC9briNBuDRQPHqmV1/jC4F8lRU+V3mGZVYIKTIQF2xbiD23gZZAaXWXZSyk5fWYAy+FnhzLceyaVzKCqQGaW1c6m97sNzTh+GfDFUcxSAgLm4gQlWjLwnNAU6YPbgYOxqGpPeALBgPDat21V8ra4v22tFJmCWtPkBVdyEBlV7x1SlKa2PRBPKWCRu64n8cLqhhkt6IFw5DdPUqvvlZuJ0B5+7jXas3Vv7lx7lbzdfk6zeGfMjSCHzQDUaTpOCs+k1xZj7CE8ZyA/GRuHIiRdlAQzay5ubXBB6GjJxe2MGYNwx0eQHOzyCe/fIzxZLjXk6qcXxKeXdelwo8dXdeUiyqrgV+SrdqijW0MSXAHB8Q2SRP2Do4aBoS4XH1hFPuO4yxgv9kmD8OFMw8ytxQz5F8VyM7i8K9dEze3FYoexYSC3vNonnIiuyPhmARnnXx5oOKvVyZt2yfH6tuKjot7AfdnuxzFZfCfcRbMFb7iAzwdVqVYDFOnmquE3qAPdvHGfuKJYQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR13MB5545.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(1800799015)(52116005)(376005)(38350700005); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: nizi4e8V7Ns3svKzLzB1/SaSqAMyJnCdwmtaEtM1GXBK1DZ/4u1KYEKvveL8m1IOI/jaue5PJ12BqheN0oIZmNJ3fmc63h8/CtkbXNFo9ZeM5bYrEGv0cdyDKV8m+vjk4WJXx3HN+Gnhj2F3HBP3KGzdqDdv2O3nAvNtOt0ddWAfBTChLcg0+s2Q2FOcrHIFA9r7QnC0lt44YX9f43R1cMt+cNCEAWC4bfIetB2PaYYgWIMMJZcAs+f2qKQs0Cl7cZ3b1m+IGXTQlpL0ljttgYuM5pfCh/sMtfdngINVinRyr8eO4idCmpMVcZsUqyvvaS0UYUUFaEX1u73UU6WpmmGDDYSJuA7IEmYdoye3XH7GqAnFtRUNC9YWjXmxsunxYu1pZSDdjvTouLMxoh6dp5MoBnxhLFN8kyJHFHWeui+O6PyD4B8wK8a/BnW8E+7VU8ssdlVSgGc8P1eTies2jUaskmphvidUwhKKbNqBLDwhcIy/PXxGa+5Bt9w3JGuhRpQqXnIxW2tosIgpRIhZt8jOmj23eIehFH+NN8Jh5AgZ6+cHnUd/0vHEQm1NZuaJgPZc8gLC0zoTO+jhtriAaz7F8Oasr165/fLxNV92RiUO4EqWDXhekATgOx/LEpCdLGp2U7ALXsJIc1rJMEpuk4h95mutIrGHP2XD4IYksYdJ1hv0qbvhciWgKxboQbLZVHcw5Sb04qyblJVqTgsuLb2eyTpxA8RkWS2uvJBeD8xFWL2HVdlutb2+auDE9Gn1k6NPuQvhxzGGVqX3lqDkggePPasaAoREHzTww3L7kPoQEtqgr7gxy1iH2cdW4Z+P4NJfwbLn5spidIjlu37m6sQT9Du9Pm850rCIvhs4QZNZsZ3xeCQbyHTsWcgaXCaRhdU6L/RoEAlQzPIrLg7brJZv5IWTtEQ2Li6pfXBOynQs/s79IQZRbpSlJlPtIOgvS41srEuLIvsuu6qhBE0PrnL2oyQyus41t3yKCC3iQU/itZUY2aGO8C8gw51pglGTuD98CHeN8PotYlc4qYrRDVA7V4jWJ3bQEIxwSwe19NWd2jC4aCjmfbQ43VQ/SRROoQNswTZ67E1uz4HK9FMN7i2+3677C25B5glp+M3q6HjR/CeeYaKemNvdvMPjADgIFnKXBzLfyQWkRppPqbbG+2R4Y/BLksc+DdDOYFCXXZKgPx0hH1xW7aMUdxn7R50fTGLQSAs4zMgz+o0po6tbEH6zZRGbZOH+dyLNsojnkeh0WPNFBlsWEW3uyrv6AroJBVJDntCAkFmBiVcMch5cXoHBJ/+ooFHjwj7FjfUn1AiuScH7EZuIYpFhgPSaDmKeqcgPmSJosMOHB2fMc9s2SoTrCr1TuXkk7jU8yecEDxCv9ZTV7Ns9Pk6UzHG7VL1sifvL1P7+cL+NZMv5lxddsaghzu7P4ie4US46FEokeSbpV96dmcziKo6l/WhsFT/z5cwilzD2Wd0eeRGaLHErjFQNWRwsp/VwBh3P6T+d6JiGgUjxXHgbDVyjVFyliU1dww2Q4pvkbJDm9imjSPREeXnivM4kfStNxek+WLJxp9vq7ltWFZQFePQdme1IgjxEJ4CWWd4XaPOZblVOiDbRHg== X-OriginatorOrg: corigine.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d8a0a5e-4f6a-47b0-de15-08dc601e9704 X-MS-Exchange-CrossTenant-AuthSource: SJ0PR13MB5545.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2024 03:12:48.0532 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: fe128f2c-073b-4c20-818e-7246a585940c X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 00maT3k1Cv8SbO9YIenQlf3MOjZJzImq3hktsQDuED6763AnxcUK1BqZND0zl8J2ttLtBRiZZYFyf7T6CqXS/zYDPmFPOkz25rd9am3bODA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA2PR13MB6587 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 |
Series |
refactor logic to support secondary process
|
|
Message
Chaoyong He
April 19, 2024, 3:12 a.m. UTC
Refactor data structure and related logic to make the secondary process can work as expect. Chaoyong He (8): net/nfp: fix resource leak of secondary process net/nfp: fix configuration BAR problem net/nfp: adjust the data field of Rx/Tx queue net/nfp: add the process private structure net/nfp: move device info data field net/nfp: unify CPP acquire method net/nfp: remove ethernet device data field net/nfp: unify port create and destroy interface drivers/net/nfp/flower/nfp_flower.c | 125 ++++---- drivers/net/nfp/flower/nfp_flower.h | 11 +- drivers/net/nfp/flower/nfp_flower_cmsg.c | 5 +- drivers/net/nfp/flower/nfp_flower_cmsg.h | 3 +- drivers/net/nfp/flower/nfp_flower_ctrl.c | 8 +- drivers/net/nfp/flower/nfp_flower_flow.c | 16 +- .../net/nfp/flower/nfp_flower_representor.c | 151 ++++++---- .../net/nfp/flower/nfp_flower_representor.h | 4 +- drivers/net/nfp/flower/nfp_flower_service.c | 32 +- drivers/net/nfp/flower/nfp_flower_service.h | 10 +- drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 +- drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 +- drivers/net/nfp/nfp_ethdev.c | 274 ++++++++++-------- drivers/net/nfp/nfp_ethdev_vf.c | 18 +- drivers/net/nfp/nfp_net_common.c | 116 ++++---- drivers/net/nfp/nfp_net_common.h | 30 +- drivers/net/nfp/nfp_net_flow.c | 20 +- drivers/net/nfp/nfp_rxtx.c | 9 +- drivers/net/nfp/nfp_rxtx.h | 69 ++--- drivers/net/nfp/nfpcore/nfp6000_pcie.c | 34 +-- 20 files changed, 523 insertions(+), 422 deletions(-)
Comments
Refactor data structure and related logic to make the secondary process can work as expect. --- v2: * Solve the build problem. --- Chaoyong He (8): net/nfp: fix resource leak of secondary process net/nfp: fix configuration BAR problem net/nfp: adjust the data field of Rx/Tx queue net/nfp: add the process private structure net/nfp: move device info data field net/nfp: unify CPP acquire method net/nfp: remove ethernet device data field net/nfp: unify port create and destroy interface drivers/net/nfp/flower/nfp_flower.c | 127 ++++---- drivers/net/nfp/flower/nfp_flower.h | 11 +- drivers/net/nfp/flower/nfp_flower_cmsg.c | 5 +- drivers/net/nfp/flower/nfp_flower_cmsg.h | 3 +- drivers/net/nfp/flower/nfp_flower_ctrl.c | 8 +- drivers/net/nfp/flower/nfp_flower_flow.c | 16 +- .../net/nfp/flower/nfp_flower_representor.c | 151 ++++++---- .../net/nfp/flower/nfp_flower_representor.h | 4 +- drivers/net/nfp/flower/nfp_flower_service.c | 32 +- drivers/net/nfp/flower/nfp_flower_service.h | 10 +- drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 +- drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 +- drivers/net/nfp/nfp_ethdev.c | 274 ++++++++++-------- drivers/net/nfp/nfp_ethdev_vf.c | 18 +- drivers/net/nfp/nfp_net_common.c | 116 ++++---- drivers/net/nfp/nfp_net_common.h | 30 +- drivers/net/nfp/nfp_net_flow.c | 20 +- drivers/net/nfp/nfp_rxtx.c | 9 +- drivers/net/nfp/nfp_rxtx.h | 69 ++--- drivers/net/nfp/nfpcore/nfp6000_pcie.c | 34 +-- 20 files changed, 524 insertions(+), 423 deletions(-)
On 4/19/2024 6:23 AM, Chaoyong He wrote: > Refactor data structure and related logic to make the secondary process > can work as expect. > Hi Chaoyong, Patchset looks good, but I have a question related to the motivation of moving so many structs to process private data? Normally ethdev is process private, and ethdev->data is shared. Primary configures the device and secondary learns shared data and uses it for datapath. There are cases, like file descriptors for same file can be different for different process and process private structure is used. In below patches, device private data level structs seems moved to the process private structure, is the intention both primary process and secondary process do the control path and configuration? If so, just a reminder that this is not intended usage of the multi-process support and many control APIs are not designed as thread-safe. Would you mind describing a little more about your use case that requires below process private data changes? > --- > v2: > * Solve the build problem. > --- > > Chaoyong He (8): > net/nfp: fix resource leak of secondary process > net/nfp: fix configuration BAR problem > net/nfp: adjust the data field of Rx/Tx queue > net/nfp: add the process private structure > net/nfp: move device info data field > net/nfp: unify CPP acquire method > net/nfp: remove ethernet device data field > net/nfp: unify port create and destroy interface > > drivers/net/nfp/flower/nfp_flower.c | 127 ++++---- > drivers/net/nfp/flower/nfp_flower.h | 11 +- > drivers/net/nfp/flower/nfp_flower_cmsg.c | 5 +- > drivers/net/nfp/flower/nfp_flower_cmsg.h | 3 +- > drivers/net/nfp/flower/nfp_flower_ctrl.c | 8 +- > drivers/net/nfp/flower/nfp_flower_flow.c | 16 +- > .../net/nfp/flower/nfp_flower_representor.c | 151 ++++++---- > .../net/nfp/flower/nfp_flower_representor.h | 4 +- > drivers/net/nfp/flower/nfp_flower_service.c | 32 +- > drivers/net/nfp/flower/nfp_flower_service.h | 10 +- > drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 +- > drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 +- > drivers/net/nfp/nfp_ethdev.c | 274 ++++++++++-------- > drivers/net/nfp/nfp_ethdev_vf.c | 18 +- > drivers/net/nfp/nfp_net_common.c | 116 ++++---- > drivers/net/nfp/nfp_net_common.h | 30 +- > drivers/net/nfp/nfp_net_flow.c | 20 +- > drivers/net/nfp/nfp_rxtx.c | 9 +- > drivers/net/nfp/nfp_rxtx.h | 69 ++--- > drivers/net/nfp/nfpcore/nfp6000_pcie.c | 34 +-- > 20 files changed, 524 insertions(+), 423 deletions(-) >
> On 4/19/2024 6:23 AM, Chaoyong He wrote: > > Refactor data structure and related logic to make the secondary > > process can work as expect. > > > > Hi Chaoyong, > > Patchset looks good, but I have a question related to the motivation of moving > so many structs to process private data? > > Normally ethdev is process private, and ethdev->data is shared. Primary > configures the device and secondary learns shared data and uses it for > datapath. > There are cases, like file descriptors for same file can be different for different > process and process private structure is used. > > In below patches, device private data level structs seems moved to the process > private structure, is the intention both primary process and secondary process > do the control path and configuration? > If so, just a reminder that this is not intended usage of the multi-process > support and many control APIs are not designed as thread-safe. > > Would you mind describing a little more about your use case that requires > below process private data changes? The main motivation of these changes is to solve the problems when customers using the secondary process (they use primary process for monitor and secondary process for rx/tx/configuration ...). The NFP card support different firmware applications, this means we need read message from firmware to decide to run which logic. And with single-pf firmware (this means one PCI BDF address for multi physical ports), we also need read message (how many ports totally) from firmware before attach to the primary process. All this relates with CPP and symbol table, and they are different for primary process and secondary process. If still put them in the process shared section (ethdev->data), the assignment logic in secondary process will overwrite it and cause the primary process crash. So we move them into the process private section (ethdev->process_private). > > > > --- > > v2: > > * Solve the build problem. > > --- > > > > Chaoyong He (8): > > net/nfp: fix resource leak of secondary process > > net/nfp: fix configuration BAR problem > > net/nfp: adjust the data field of Rx/Tx queue > > net/nfp: add the process private structure > > net/nfp: move device info data field > > net/nfp: unify CPP acquire method > > net/nfp: remove ethernet device data field > > net/nfp: unify port create and destroy interface > > > > drivers/net/nfp/flower/nfp_flower.c | 127 ++++---- > > drivers/net/nfp/flower/nfp_flower.h | 11 +- > > drivers/net/nfp/flower/nfp_flower_cmsg.c | 5 +- > > drivers/net/nfp/flower/nfp_flower_cmsg.h | 3 +- > > drivers/net/nfp/flower/nfp_flower_ctrl.c | 8 +- > > drivers/net/nfp/flower/nfp_flower_flow.c | 16 +- > > .../net/nfp/flower/nfp_flower_representor.c | 151 ++++++---- > > .../net/nfp/flower/nfp_flower_representor.h | 4 +- > > drivers/net/nfp/flower/nfp_flower_service.c | 32 +- > > drivers/net/nfp/flower/nfp_flower_service.h | 10 +- > > drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 +- > > drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 +- > > drivers/net/nfp/nfp_ethdev.c | 274 ++++++++++-------- > > drivers/net/nfp/nfp_ethdev_vf.c | 18 +- > > drivers/net/nfp/nfp_net_common.c | 116 ++++---- > > drivers/net/nfp/nfp_net_common.h | 30 +- > > drivers/net/nfp/nfp_net_flow.c | 20 +- > > drivers/net/nfp/nfp_rxtx.c | 9 +- > > drivers/net/nfp/nfp_rxtx.h | 69 ++--- > > drivers/net/nfp/nfpcore/nfp6000_pcie.c | 34 +-- > > 20 files changed, 524 insertions(+), 423 deletions(-) > >
On 5/21/2024 3:17 AM, Chaoyong He wrote: >> On 4/19/2024 6:23 AM, Chaoyong He wrote: >>> Refactor data structure and related logic to make the secondary >>> process can work as expect. >>> >> >> Hi Chaoyong, >> >> Patchset looks good, but I have a question related to the motivation of moving >> so many structs to process private data? >> >> Normally ethdev is process private, and ethdev->data is shared. Primary >> configures the device and secondary learns shared data and uses it for >> datapath. >> There are cases, like file descriptors for same file can be different for different >> process and process private structure is used. >> >> In below patches, device private data level structs seems moved to the process >> private structure, is the intention both primary process and secondary process >> do the control path and configuration? >> If so, just a reminder that this is not intended usage of the multi-process >> support and many control APIs are not designed as thread-safe. >> >> Would you mind describing a little more about your use case that requires >> below process private data changes? > > The main motivation of these changes is to solve the problems when customers using the > secondary process (they use primary process for monitor and secondary process for rx/tx/configuration ...). > Got it, if you want to do 'configuration' on the secondary, it requires more information, and as this is not shared you need to move them to process private. This approach requires synchronizing secondaries for this control path. So more work for the application layer. I understand you are trying to enable your customer, and this is a solution but I am not sure this is the best approach. And this solution won't be portable, because many PMDs won't support configuring from secondary. Can you guide your customer that configuring on primary and limit secondaries for the datapath? This way only some limited information is required to shared with secondaries (lets say like firmware application version) and these can be passed via shared data or even MP communication. Although this is not a hard requirement, I believe this can make both your and your customer's life easier in long run. > The NFP card support different firmware applications, this means we need read message from firmware to > decide to run which logic. > > And with single-pf firmware (this means one PCI BDF address for multi physical ports), we also need > read message (how many ports totally) from firmware before attach to the primary process. > > All this relates with CPP and symbol table, and they are different for primary process and secondary process. > If still put them in the process shared section (ethdev->data), the assignment logic in secondary process will overwrite it > and cause the primary process crash. > > So we move them into the process private section (ethdev->process_private). >
> On 5/21/2024 3:17 AM, Chaoyong He wrote: > >> On 4/19/2024 6:23 AM, Chaoyong He wrote: > >>> Refactor data structure and related logic to make the secondary > >>> process can work as expect. > >>> > >> > >> Hi Chaoyong, > >> > >> Patchset looks good, but I have a question related to the motivation > >> of moving so many structs to process private data? > >> > >> Normally ethdev is process private, and ethdev->data is shared. > >> Primary configures the device and secondary learns shared data and > >> uses it for datapath. > >> There are cases, like file descriptors for same file can be different > >> for different process and process private structure is used. > >> > >> In below patches, device private data level structs seems moved to > >> the process private structure, is the intention both primary process > >> and secondary process do the control path and configuration? > >> If so, just a reminder that this is not intended usage of the > >> multi-process support and many control APIs are not designed as thread- > safe. > >> > >> Would you mind describing a little more about your use case that > >> requires below process private data changes? > > > > The main motivation of these changes is to solve the problems when > > customers using the secondary process (they use primary process for > monitor and secondary process for rx/tx/configuration ...). > > > > Got it, if you want to do 'configuration' on the secondary, it requires more > information, and as this is not shared you need to move them to process > private. > > This approach requires synchronizing secondaries for this control path. > So more work for the application layer. > > I understand you are trying to enable your customer, and this is a solution but > I am not sure this is the best approach. And this solution won't be portable, > because many PMDs won't support configuring from secondary. > > Can you guide your customer that configuring on primary and limit > secondaries for the datapath? Sorry, but it is almost certain that it is impossible to make customer modify their architecture. Because they have complex software stack, and they themselves are only user of the software stack. They are just responsible for the basic NIC adaptation work and the upper software architecture are design and maintain by some other department. For this generation NFP hardware and firmware architecture, seems this is the only best solution we can achieve. But for the next generation NIC and firmware (we already in development, and will publish in a near future), we will have one PCI BDF address for one physical port and use a unified firmware. Then the problems we meet for now will not exist anymore, and we can make the logic just as what you said. > This way only some limited information is required to shared with secondaries > (lets say like firmware application version) and these can be passed via shared > data or even MP communication. > > Although this is not a hard requirement, I believe this can make both your and > your customer's life easier in long run. > > > > The NFP card support different firmware applications, this means we > > need read message from firmware to decide to run which logic. > > > > And with single-pf firmware (this means one PCI BDF address for multi > > physical ports), we also need read message (how many ports totally) from > firmware before attach to the primary process. > > > > All this relates with CPP and symbol table, and they are different for primary > process and secondary process. > > If still put them in the process shared section (ethdev->data), the > > assignment logic in secondary process will overwrite it and cause the primary > process crash. > > > > So we move them into the process private section (ethdev- > >process_private). > > > >
On 5/21/2024 12:24 PM, Chaoyong He wrote: >> On 5/21/2024 3:17 AM, Chaoyong He wrote: >>>> On 4/19/2024 6:23 AM, Chaoyong He wrote: >>>>> Refactor data structure and related logic to make the secondary >>>>> process can work as expect. >>>>> >>>> >>>> Hi Chaoyong, >>>> >>>> Patchset looks good, but I have a question related to the motivation >>>> of moving so many structs to process private data? >>>> >>>> Normally ethdev is process private, and ethdev->data is shared. >>>> Primary configures the device and secondary learns shared data and >>>> uses it for datapath. >>>> There are cases, like file descriptors for same file can be different >>>> for different process and process private structure is used. >>>> >>>> In below patches, device private data level structs seems moved to >>>> the process private structure, is the intention both primary process >>>> and secondary process do the control path and configuration? >>>> If so, just a reminder that this is not intended usage of the >>>> multi-process support and many control APIs are not designed as thread- >> safe. >>>> >>>> Would you mind describing a little more about your use case that >>>> requires below process private data changes? >>> >>> The main motivation of these changes is to solve the problems when >>> customers using the secondary process (they use primary process for >> monitor and secondary process for rx/tx/configuration ...). >>> >> >> Got it, if you want to do 'configuration' on the secondary, it requires more >> information, and as this is not shared you need to move them to process >> private. >> >> This approach requires synchronizing secondaries for this control path. >> So more work for the application layer. >> >> I understand you are trying to enable your customer, and this is a solution but >> I am not sure this is the best approach. And this solution won't be portable, >> because many PMDs won't support configuring from secondary. >> >> Can you guide your customer that configuring on primary and limit >> secondaries for the datapath? > > Sorry, but it is almost certain that it is impossible to make customer modify their architecture. > Because they have complex software stack, and they themselves are only user of the software stack. > They are just responsible for the basic NIC adaptation work and the upper software architecture are > design and maintain by some other department. > > For this generation NFP hardware and firmware architecture, seems this is the only best solution > we can achieve. > > But for the next generation NIC and firmware (we already in development, and will publish in a near future), > we will have one PCI BDF address for one physical port and use a unified firmware. > Then the problems we meet for now will not exist anymore, and we can make the logic just as what you said. > Ack, it looks like you are making an informed decision, although it is not ideal, I will proceed with the set. >> This way only some limited information is required to shared with secondaries >> (lets say like firmware application version) and these can be passed via shared >> data or even MP communication. >> >> Although this is not a hard requirement, I believe this can make both your and >> your customer's life easier in long run. >> >> >>> The NFP card support different firmware applications, this means we >>> need read message from firmware to decide to run which logic. >>> >>> And with single-pf firmware (this means one PCI BDF address for multi >>> physical ports), we also need read message (how many ports totally) from >> firmware before attach to the primary process. >>> >>> All this relates with CPP and symbol table, and they are different for primary >> process and secondary process. >>> If still put them in the process shared section (ethdev->data), the >>> assignment logic in secondary process will overwrite it and cause the primary >> process crash. >>> >>> So we move them into the process private section (ethdev- >>> process_private). >>> >> >> >
On 4/19/2024 6:23 AM, Chaoyong He wrote: > Refactor data structure and related logic to make the secondary process > can work as expect. > > --- > v2: > * Solve the build problem. > --- > > Chaoyong He (8): > net/nfp: fix resource leak of secondary process > net/nfp: fix configuration BAR problem > net/nfp: adjust the data field of Rx/Tx queue > net/nfp: add the process private structure > net/nfp: move device info data field > net/nfp: unify CPP acquire method > net/nfp: remove ethernet device data field > net/nfp: unify port create and destroy interface > Series applied to dpdk-next-net/main, thanks.