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 EF58F424EC; Mon, 4 Sep 2023 09:46:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C0568402D2; Mon, 4 Sep 2023 09:46:04 +0200 (CEST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2054.outbound.protection.outlook.com [40.107.212.54]) by mails.dpdk.org (Postfix) with ESMTP id 31D01402D0; Mon, 4 Sep 2023 09:46:03 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U4Lu62intf2wKIiStwwLPLJc9RhQUOl3uKJEcbdSaGPEuKTDaMJd+PWjgrvx7Np4jDkmsOGbdUJTRki97HxTlExe/HWoZcW2Elp6S7UE5Qx+deK2fTiiaN0rHhXPcFsl6ca//nklBXSM85XwgKYuk3xTuK5+mVL2mADDdEQoSZqaRHvMQJgTV0SiBi9UtDLvVUwmvrUcNytwI2GT7jJjgovbmXBwH3q4auz5mPEi3vsHI7/BUaH/NTvLXzHQY3nsNYYVbRJL//VQA5AOtG4RylaeMJB16JVP1dzRdHAp1mTXNqrDAuUVnQPL81Z1ZBWn67k322pFqOKaifdGMJ+2CQ== 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=DxtFF+C3Edto6PU+MUZFcWwDsa9BvU7P8rsqREvml0s=; b=UEPG+fmOwULqTEQzxHnQhw+eDI6cQ5PfuBkyADDnFyOG16s/jZiAPctl1fK3/bOpmF/dCuJapvplYjG1jWQ4HHLpyjvEHbyVHeJJvqjZiVNnIVOeMb+Mfp0lEB0elD278hasijPGz1OPLcHEAgd4bGePoTBZPqT/C8rBVN6fkct0ra/xYsWre5SUAtWqsX03m7D9ysq5FrP3bDIlEpy/OI8jUq4e+IoUu5XgZypm9gSxdIN13zqnHNGjcvCY4mPJHinHJlftAd9TrTs9qx3J1MRv/F2m0YmdUSMIW7QJc7swRimZ9PS9fQTO4UZoSFxVR/ZC0dGEB3mX1x59W8N1mA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DxtFF+C3Edto6PU+MUZFcWwDsa9BvU7P8rsqREvml0s=; b=PPSyuiy/5u0mBJOOa9khxA8cQWuFvZE7M5nd3hIXQGFIKGEKZWnOXJGg2mt1ppUOlBYUjD9LJkMrmK/jVPG2FC6eobSKmunyPtUnL6BfiC6t+xQ10caRfr98+j/AMjTy3BzNwmNpBLSA0THDcZpw6Qmn3+4BgLUecQ/PPkfS92E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by IA0PR12MB7749.namprd12.prod.outlook.com (2603:10b6:208:432::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6745.30; Mon, 4 Sep 2023 07:46:01 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::49e9:2bf6:7f06:bbbd]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::49e9:2bf6:7f06:bbbd%3]) with mapi id 15.20.6745.030; Mon, 4 Sep 2023 07:46:00 +0000 Message-ID: Date: Mon, 4 Sep 2023 08:45:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: Jerin Jacob , Ori Kam Cc: "Dumitrescu, Cristian" , =?UTF-8?Q?Morten_Br=c3=b8rup?= , "Zhang, Qi Z" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "david.marchand@redhat.com" , "Richardson, Bruce" , "jerinj@marvell.com" , "techboard@dpdk.org" , "Mcnamara, John" , "Zhang, Helin" , "dev@dpdk.org" References: <20230802173451.3151646-1-qi.z.zhang@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D87AC4@smartserver.smartshare.dk> <5228976a-5990-bc5c-28d9-b2774abbb783@amd.com> Content-Language: en-US From: Ferruh Yigit Subject: Re: DPDK community: RTE_FLOW support for P4-programmable devices In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0504.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:13b::11) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|IA0PR12MB7749:EE_ X-MS-Office365-Filtering-Correlation-Id: 7bd4769b-3436-46bf-38c8-08dbad1afb18 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bllJ4EwAibjS+pt6MYfPzhCND+L6RuDdVAaz/u0c8im7+zcN+eRDAzPKocR6omMXb8NQJ0rUautUvLRD+Q97RRSIveyqsq9TYl+DyPKU72R5BCd6AOcyRocc10XukDJGrXc4/0c93kkbCvQc9/3xgiWKQR8QeYgI72X9rLBDjzFLv72kbTqx6q7/ehsRgmJr7rO5Px9JKDSJBVvGut+n7tBDYJ56MOPn9SWziF0OtkVG6d3npLljf1X6D+ry8OA3fY5ScCMM8cKSsadOs5FcCcMXkzh1cgq+dIHWOLFqMYPVZ83j1NfYcCe1ZzDxoDxKh6wvcjHM/Dwy2n5hrsDDu1Z+/ZvpnDq8haZi2kfQh6QZbodma0LsANIfABOuraDZMgpuBDbo35Q14ekLCCJNInPcMzlQU3xOYN0liur6e2SzaZCod3zwfH8/Hx/D7dmzhCxe+fIWTHyoGJlUUSs8Obu2ooqrHuYroFdTSfnwFkFNrdAK+MYTlosjN7zgzt7GKWdOb4v8aLE2tocyem9EQnWN+Ww87mfzXgkNmV/4AvwUoiOt9dDWl8DzV/ibzy+YBL5b8OP8BATSnVZriL1balqxBa0/CAjV/+0B6WJIXBsmFzT1Igv065RI9mP30VLxe0Ikyn593NamH+QxCH9lOXak3LYuEhTkUDEyrBbZMXw= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(136003)(39860400002)(396003)(366004)(346002)(451199024)(186009)(1800799009)(31686004)(66476007)(66556008)(2906002)(110136005)(36756003)(54906003)(66946007)(86362001)(31696002)(316002)(5660300002)(44832011)(8936002)(4326008)(8676002)(41300700001)(6512007)(2616005)(83380400001)(26005)(38100700002)(7416002)(478600001)(6506007)(6486002)(6666004)(53546011)(21314003)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?d2szSjlOZjNLYzNoZmJWVDNFNUxVd1RLbE9MTC9HdzdXd2VXcVNWOU5CdlIw?= =?utf-8?B?SXlhbnF3UkRCeUlXUVJIM29yUG9hd1J3cXR6TkErbmNacWxiYmwwM21aV25I?= =?utf-8?B?SlcxS1dGaytmYndXVnVEWm9wM2lWdm5qamMxWGsrTW1SQXVFTCs2WnNjMXcy?= =?utf-8?B?YmtWRFUydEcvb1NXTTZjWUdGNDNsaEs4TFJFU3ZFOG1mTjdTeVBlT1BQSFcy?= =?utf-8?B?Rm1RRGtFcndMWlI5WVdEZXhwczJmUGsxenRWMEFZdXpjN0IzZWZ5eUlUOVVG?= =?utf-8?B?RjR6WGprdEprN1YwT3VpamFyNVlmUDJtU05WS0FPS0srMk9nZ2loSUJUMUJj?= =?utf-8?B?aHpHQzE3bHlDenFzUDNMYVoveFlxWHZiT1FrOWk5cUlHdXZodEs3bllzTy9w?= =?utf-8?B?ai91QXlMUHZqTENqQ3pIWGV0Q0tsRU4xMWtKTk9mUmdZeC9DUTNTZWc2ZlBO?= =?utf-8?B?V2xPS3hkMVpnaVdGZ2p4R1EvZnhxMzB5eHNtQlU2YWxMMDgyRis1L3FQRlZp?= =?utf-8?B?dzNUekJnT0szL1pkRnhlVHZ4N2lGaU9HaTU3L1c2T0dWYmNrRkFIVFVMNVNU?= =?utf-8?B?SUo5bEhnUXJob3h2elh1dzR2emFGMThGRkc5RTl4OXdOY25rSUNTUFlkOUdC?= =?utf-8?B?NStmM0xpZ0RMZjE3UXdoUXNrTmpPc2hjWTg3UlIyakFLbEJ5WmdRbUlMaGg0?= =?utf-8?B?dEhLR1lyVjlRTUg3b0did25OeEFvaWdWeU45UTdOWTFWU05UanRxYlFiSWUr?= =?utf-8?B?RU11blNaTXBDYTdTQjRjakFwQVJSNVBGNTVNUVBEekFTcnRucXg1ZmpRVjQr?= =?utf-8?B?OGVBVnlCeml0K2V1eXdpQi80Y1NXUlNsMzJwNVhBVFpyaGNrUit0OXpMSTc0?= =?utf-8?B?T1JWNmNuZVJ1bHl3WVZRT01Cell1ZldlaytVQ0RlTUhBZ09yY3MzVlRab05P?= =?utf-8?B?OGxvdEhKSTFBYlU4TWVqVGlxUlVOSEd5eW1EbEw0bkRrYUNLeVZiZzBEU0NU?= =?utf-8?B?c25mcGZQTXV4RTNUN3dTWFk5K3gvdnlzUGg3aFlLVkZ3bHh1K0NuRlhCOE9T?= =?utf-8?B?UTI1b1Z5bUYvcnIyeTQ3YXFINVVMdmU5U0FUSGJDbzJKTUkremhKT2RldUJG?= =?utf-8?B?RnNTR0Rtaml0a01GRnVtd1BFMG5GRzFzSUx6VzJqVlI2N1ZuOUdpTUZzYmVZ?= =?utf-8?B?OUZjdVJvL3dNU3VFUnUxMUhDeVBQdTdmSExleXArdmlJdzRaSEFMbXZqbjU0?= =?utf-8?B?czh3S0wzcUZ3L3Uxdk1PWDRrNk1NbTB1WTI4aUxQYmVGM2lFYnhubG5oL210?= =?utf-8?B?UUVVU3FTcmxXUCtDVEl5SUQvbEIyOVlGM3RMNldnTitpWE5Kc3BYMTdaQVBt?= =?utf-8?B?MHQvd2YyMkw4bTM1Ty8vK1ZXUmc3QkJEMWFPdGJkV2xWV3Y1VXI4L01jSU1P?= =?utf-8?B?NGZ3VlJGRVZCdGVxYVpVNTZONTliTkZJdnJnbDdGZ1JFcEtJUzhKSnZGaUND?= =?utf-8?B?RXl4Wk1acUIxZk8rSStYb1FuMlVDMEpaWWxZZUhaN2dKdWlnK0xZejlMeWJN?= =?utf-8?B?YU81Vk10U3FJV0t5NHhZMDl1VHRLMHBNandxMXd5NDVrTEc4YWQ3Z1JVZmlr?= =?utf-8?B?OUd1c0NNNVBPU3N2WEFXRXdzYmRydUVoNzlnYzZmRDR4TVZHOEFUQ1M0ZVFt?= =?utf-8?B?WUw4VTFGa2g5TXVCOGJnVXdpMDVKaHBqM2gvaXY5QjdCTDFGNFNRdUREZStt?= =?utf-8?B?dHVIdTNPRm9zZERJc1ExbEI0eFZDbjdqdEgyTmVERHBGNDI4dUd6ZHZmdk1D?= =?utf-8?B?ZmFlOHpKMUExN2lxcU54Z0dVRG43KytXU2ZOMURTQ3N6eWNiRlY4NGpQS29q?= =?utf-8?B?dWtFTDNlV3ZwOFhxYXJOOWJiS2Z1akZPVlNkb0xodmJsQnJSaGZ2TDB6S2RI?= =?utf-8?B?N29JcWNLK3ZxMEZkVWRCRmpmYk55bmFIQkJ2SGRkL3MwWFN5RVQyeUJPM3Iw?= =?utf-8?B?T2hDaWNKSGR5dEh0dytiN1FIYlVzSXI0VFQ4bkpNNlRlY0JVYSsxM3h6c2F2?= =?utf-8?B?RDZXalRhNTNpMVZzczdkN2NGNHY2UjZBKy9aTmFSZWJpOXlqQm91ODNGbWk0?= =?utf-8?Q?iABNyEI2zESYLh+uWmUfReWpR?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bd4769b-3436-46bf-38c8-08dbad1afb18 X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Sep 2023 07:45:59.9147 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2LFj7TfTwUOgx/9Qxx5VoSBEbRpMBl/pCMbu7kLzay/K4aGNKfzo7iLdNUkOEVmV X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7749 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 On 9/1/2023 10:52 AM, Jerin Jacob wrote: > On Fri, Sep 1, 2023 at 12:27 PM Ori Kam wrote: >> >> >> >>> -----Original Message----- >>> From: Jerin Jacob >>> Sent: Friday, September 1, 2023 5:07 AM >>> >>> On Thu, Aug 31, 2023 at 4:02 PM Ori Kam wrote: >>>> >>>> Hi >>> >>>>>>> >>>>>>> 3. Everybody on the call agreed that the P4-programmable devices from >>>>> Intel, >>>>>>> AMD and others need to be fully supported by DPDK and that there are >>>>> some >>>>>>> gaps in RTE_FLOW to be fixed for supporting these devices. >>>>>> >>>>>> Personally, It makes sense to me to have normative DPDK API to send p4 >>>>>> runtime message to the >>>>>> ethdev so that we have "vendor neutral + DPDK based" p4 runtime >>> backend. >>>>>> >>>>>> I prefer to have specialized ethdev ops for this due to the following >>> reasons. >>>>>> >>>>>> # If the ethdev has both real TCAM based HW(for existing rte_flow >>>>>> patterns and actions) and SW agent to receive P4 runtime message etc. >>>>>> Typically, it needs to take a different path in driver to talk. Assume, if you >>>>>> have cascaded patterns/actions, One is targeted for TCAM and other for >>>>>> SW agent for p4, one >>>>>> need to have serious amount checking for dispatching.It complicates >>>>>> the driver and forbid to have >>>>>> driver optimization especially cases for templates etc. if user making >>>>>> rules for both category of HW. >>>>>> >>>>> >>>>> Indeed I am not against dedicated APIs for P4 runtime backend. >>>>> >>>>> But assuming there is a dedicated rte_flow item for P4, how it is >>>>> different than dedicated API in above scenario? >>>>> If driver detects P4 runtime specific rule, it can bail it out to SW agent. >>>>> Can you please elaborate the complexity it introduces? >>> >>> Assume, normal existing rte-flow programming include a bunch of >>> register writes and >>> p4 runtime backend is more of SW ring. If a template has both patterns >>> and actions >>> as cascaded, it will be difficult for driver to optimize the template. >>> I assumed P4 specific item/action can take completely separate path, do you think existing rte_flow item/actions and P4 item/actions can mix in same rte_flow rule? >>> >>>>> >>>>>> # All we need "char buffer//string" based communication ethdev <-> app. >>>>>> >>>>> >>>>> Yes, and both a dedicated API or dedicated rte_flow item can provide >>>>> medium for this communication. >>>>> >>>>> rte_flow one has flexibility & extensibility advantages, but maybe not >>>>> as straightforward as an API. >>>> >>>> I think not using the rte_flow will also require duplication of all the rule >>> handling functions and table creations, for example aync rule create/destroy >>> query ...... >>> >>> Yes. That is a fair point. I am OK with exposing as rte_flow. >>> As a driver implementation note, to get rid of the above problem, >>> driver can choose to have pseudo ethdev devices for p4 if needed(if >>> driver finds difficult to combine TCAM based on HW rules and p4 >>> runtime rule). >>> >> >> What about the following concept: >> The p4 compiler can generate the translation to known PMD objects in rte_flow, >> then when a command is sent from the p4 agent to the offload using GRPC or any other way, the DPDK will convert from >> p4 protocol to rte_flow commands (this should be very fast since the commands are known and the mapping is already >> defined). >> >> To support the above idea we need to add two new functions to rte_flow (each function will be implemented in PMD level) > > If the implemention of rte_flow_p4_runtime((p4 command based on the p4 spec)) > is defined in PMD level, The PMD driver to decide to use rte_flow or > something else. > I think it is good, this is actually going back to specialized API. > BTW, rte_flow prefix is not needed in that case. > +1 this is leaning to the dedicated API option. > > >> Rte_flow_register_p4(void *p4_info, void *p4_blob) >> { >> Creates the static structures/objects >> Internal register the p4 commands to PMD translation table. >> } >> >> Rte_flow_p4_runtime(p4 command based on the p4 spec) >> { >> Based on the registered mapping, translate the command to rte_flow commands. >> Rte_flow_xxx() calls For the 'rte_flow_xxx()' calls here, my understanding is existing rte_flow calls are not sufficient to meet the requirement to program the P4 pipeline, that is why this patch is about defining the new flow item. If these are not rte_flow calls but PMD defined code, than it is not much different from previously suggested dedicated API solution. >> } >> >> As far as I see, the above code will also allow PMD to implement internal logic if needed, while from DPDK API, >> we will only add two new functions. >> >>> >>>>