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 4530C43A02; Mon, 29 Jan 2024 18:36:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4D7C4029A; Mon, 29 Jan 2024 18:36:25 +0100 (CET) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2059.outbound.protection.outlook.com [40.107.237.59]) by mails.dpdk.org (Postfix) with ESMTP id 6987F4026F for ; Mon, 29 Jan 2024 18:36:24 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mbbITOZd5EscnK6r/Bgn5J3j0nUijtCiC9p6E+GQAkVv5cq/zv9D/dEX2yRrTES7xjnfhtnv57k2lbLriNhBqCU/Ln5rdSnkjzwQjevk68JSVVjhNHrCRqs2fLMEwa+QfOGNSMMT4PY2zO1fwQAa3G4RBVApxlBJ1kq9T+04CFqHvI/NEf3OorW1BeA3sBqlryv2AL9rEOpTS5b8cIWv2xJDgODPlbHHi7Ib2pAm7RqDzi+afMJi08BwFaoUGghRKuzh7A6gnjLO+fegJAFwFlR+W9k7OIaM83T6JiVE3rOcWwoOz/DfxUoNFBkhJYyUPp9aTnkLpMyyntbLsr2UXw== 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=lQBvxHTiFHtBGybc6pby3yslENyk8l1nKUO0ry36yTs=; b=knZXL33N/hCXucjxn2o+io8kiwzuEvn1LGGUmrZDYAYhx50ptnM+ec7CmnV9b/+TTTk80vFCBozXsO5lbllGdWJFc9wvHvA7CQVW2I+P6wVw4loBaSvRzd+gBc+4/frIDaFLxdYFjYc74+kFrQ2oLVI/u9WBd5/Uu77JdWTZmKfF7PlFjLwhdpkT6TJEhzUow5XCO9TIpJJFlt+mR36QVnH65YIDD/wYQSEYLibTDA266DDSngbfPW6dc5feDmiLiMA1Br0nFrb5uN/bJ8cUTzfm48r4XFP6MBndwn2a51uz/WLqtPArhchwDBUQSGMeQfnuoMOI2sUs3Il1Yk7dLA== 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=lQBvxHTiFHtBGybc6pby3yslENyk8l1nKUO0ry36yTs=; b=TpMLdznYoVOOxx7Hmw4df1uTekf5KOAkJC1JlJSYDES6bceT4bWAxmctIHID5I5YyEkVZ2SeskLZBUI1lnUkkNs7J/AJ6Z8iZALONSyhEv/mieeEkUheAiItox6+tr44tQ/PO45dUcCVg6u4uEcjyLzdzMnsWknADql1dmghBd4= 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 CH2PR12MB4859.namprd12.prod.outlook.com (2603:10b6:610:62::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.34; Mon, 29 Jan 2024 17:36:21 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::815a:45e6:cf5e:479f]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::815a:45e6:cf5e:479f%4]) with mapi id 15.20.7228.029; Mon, 29 Jan 2024 17:36:21 +0000 Message-ID: <97bbc06c-3baf-43fd-930d-27b01007f672@amd.com> Date: Mon, 29 Jan 2024 17:36:15 +0000 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] ethdev: fast path async flow API Content-Language: en-US To: Dariusz Sosnowski , Stephen Hemminger Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Andrew Rybchenko , Ori Kam , "dev@dpdk.org" References: <20231227105709.1951231-1-dsosnowski@nvidia.com> <20231228091657.14769682@hermes.local> <20240103170758.119e99d4@hermes.local> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@amd.com; keydata= xsFNBGJDD3EBEAC/M7Tk/DfQSmP1K96vyzdhfSBzlCaGtcxNXorq4fALruqVsD3oi0yfyEz9 4YN8x7py0o9EL8ZdpOX0skc0AMCDAaw033uWhCn0GLMeGRKUbfOAPvL6ecSDvGD7CJIO9j0J eZUvasBgPdM/435PEr9DmC6Ggzdzt8IuG4PoLi5jpFSfcqxZFCCxLUDEo/w0nuguk2FTuYJg B2zEZ4JTBZrw7hIHiFh8D8hr6YA6a5uTofq1tr+l048lbtdFUl8TR0aIExVzE4Z8qKZlcE+9 RQaewjK5Al1jLE4sHdmd3GN+IvgDF3D/fLsi25SKJDeGSdeHkOmaX0qGeM4WKIfU6iARRCiQ N3AmBIxZ/A7UXBKLaOyZ+/i3sE6Wb53nrO4i8+0K2Qwyh6LjTeiJAIjYKN43ppxz3DaI+QwQ vI+uyHr4Gg0Da9EPPz/YyKauSeOZCfCB5gIfICO0j6x0SCl8uQ2nLpjxcZkf0gjcwUzP3h+S 3x6NfDji9YEij0zczW/dcSpGgZ6vsFpPrtnP9ZXy6J53yp0kJtOJoOlkEFFdU2yCZnCDseum CoudmGLZVvS0/DzHDJejq+3kK3FDGktZBOxZIIpal+nFqS7lVgOZc4+huVv3jyhzoAUOEyXA XK5j6o7g8STUY+z33QNnHpdLvecMwuzmvqy0jR54yAbZ64mB9QARAQABzSNGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBhbWQuY29tPsLBlwQTAQgAQQIbAwULCQgHAgYVCgkICwIEFgID AQIeAQIXgAIZARYhBEm7aYjps5XGsPHCElRTPtCKKm/6BQJkdyEEBQkE3meNAAoJEFRTPtCK Km/6UdcP/0/kEp49aIUhkRnQfmKmNVpcBEs4NqceNCWTQlaXdEwL1lxf1L49dsF5Jz1yvWi3 tMtq0Mk1o68mQ7q8iZAzIeLxGQAlievMNE0BzLWPFmuX+ac98ITBqKdnUAn6ig5ezR+jxrAU 58utUszDl16eMabtCu76sINL5izB8zCWcDEUB4UqM8iBSQZ7/a7TSBVS0jVBldAORg1qfFIs cGMPQn/skhy3QqbK3u3Rhc44zRxvzrQJmhY6T1rpeniHSyGOeIYqjpbpnMU5n1VWzQ4NXvAD VDkZ4NDw6CpvF4S2h2Ds7w7GKvT6RRTddrl672IaLcaWRiqBNCPm+eKh4q5/XkOXTgUqYBVg Ors8uS9EbQC/SAcp9VHF9fB+3nadxZm4CLPe5ZDJnSmgu/ea7xjWQYR8ouo2THxqNZtkercc GOxGFxIaLcJIR/XChh9d0LKgc1FfVARTMW8UrPgINVEmVSFmAVSgVfsWIV+NSpG9/e90E4SV gMLPABn1YpJ8ca/IwqovctqDDXfxZOvCPOVWTzQe/ut767W+ctGR1kRkxWcz470SycOcY+PW VRPJd91Af0GdLFkwzZgNzkd6Gyc9XXcv4lwwqBLhWrBhqPYB0aZXIG1E/cVTiRp4dWpFHAFD DcuLldjIw93lCDsIeEDM9rBizGVMWEoeFmqSe7pzGTPXzsFNBGJDD3EBEAC8fBFQHej8qgIG CBzoIEd1cZgPIARlIhRudODXoNDbwA+zJMKtOVwol3Hh1qJ2/yZP11nZsqrP4fyUvMxrwhDe WBWFVDbWHLnqXMnKuUU1vQMujbzgq/4Rb9wSMW5vBL6YxhZng+h71JgS/9nVtzyaTtsOTrJi 6nzFSDx6Wbza2jYvL9rlK0yxJcMEiKwZQ/if4KcOesD0rtxomU/iSEv6DATcJbGXP6T93nPl 90XksijRKAmOwvdu3A8IIlxiSSVRP0lxiHOeR35y6PjHY2usfEDZZOVOfDfhlCVAIBZUZALv VmFOVSTYXeKgYa6Ooaf72+cHM3SgJIbYnevJfFv8YQW0MEAJ/IXE7B1Lk+pHNxwU3VBCrKnA fd/PTvviesuYRkrRD6qqZnINeu3b2DouVGGt2fVcGA38BujCd3p8i7azoGc7A6cgF7z9ETnr ANrbg1/dJyDmkDxOxVrVquTBbxJbDy2HaIe9wyJTEK2Sznpy62DaHVY+gfDQzexBXM10geHC IIUhEnOUYVaq65X3ZDjyAQnNDBQ4uMqSHZk8DpJ22X+T+IMzWzWl+VyU4UZXjkLKPvlqPjJk 1RbKScek5L2GhxHQbPaD76Hx4Jiel0vm2G+4wei8Ay1+0YRFkhySxogU/uQVXHTv63KzQMak oIfnN/V2R0ucarsvMBW+gwARAQABwsF8BBgBCAAmAhsMFiEESbtpiOmzlcaw8cISVFM+0Ioq b/oFAmR3IPsFCQTeZ44ACgkQVFM+0Ioqb/qINhAAtcor9bevHy22HvJvXX17IOpPSklZJAeQ Az43ZEo5kRlJ8mElc2g3RzYCvL/V3fSiIATxIsLq/MDtYhO8AAvklxND/u2zeBd7BkRZTZZX W1V1cM3oTvfx3LOhDu4f2ExQzCGdkzbXTRswSJIe1W0qwsDp+YPekbrsKp1maZArGeu+6FuW honeosIrWS98QJmscEhP8ooyJkLDCCOgEk+mJ/JBjzcJGuYn6+Iy/ApMw/vqiLGL1UWekcTA g18mREHqIR+A3ZvypIufSFB52oIs1zD/uh/MgmL62bY/Cw6M2SxiVxLRsav9TNkF6ZaNQCgn GqifliCEMvEuLZRBOZSYH2A/PfwjYW0Ss0Gyfywmb2IA990gcQsXxuCLG7pAbWaeYazoYYEQ NYmWatZNMAs68ERI2zvrVxdJ/fBWAllIEd0uQ4P05GtAHPdTIDQYp545+TPV7oyF0LfXcsQs SFVZE6igdvkjfYmh+QOrHGZvpWXLTmffVf/AQ81wspzbfxJ7sYM4P8Mg5kKOsaoUdyA/2qVe cMh1CLUHXF1GlofpGbe1lj4KUJVse5g3qwV7i9VrseA8c4VIZewdIjkzAhmmbxl+8rM/LKBH dZUMTzME5PFCXJIZ83qkZQ795MTe2YScp9dIV7fsS5tpDwIs7BZNVM1l3NAdK+DLHqNxKuyO 8Zk= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0114.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:9d::6) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|CH2PR12MB4859:EE_ X-MS-Office365-Filtering-Correlation-Id: dd479ec7-ceb7-4fcf-fc3a-08dc20f0ce5d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: t9ZFWJ6NN+POo61K4vL1Y9cWGcwYxc4vRx2DOnHx2u9+prbURTC5aV6IcrGQMk4fqdcVei8xwDWSO6Q3KHbDY4KcRFwzEAdGFfWIPfaHUr+3/7W30qjBAOTvdCj3u3Ljf3ptHTWyOHP4hK2u3d3EPKXSlDGTWSGLWe/Yb+xvuYdyH0zNwn5dVzYeyDuLkQZlFK7KAzLtbOgkx+GpZVCDhKLkRU0llY0IuRjdQmeHJMtDcd+gfMCtc9FIsNk2whsvPpk7OLl7SATAfYosuSvY9TQlE7GCLYLicvwi5aTGxLqzIOJqSUhOUf0K/dsoUDFuGrpVLa66sdEIq3zsUEgQ9MD0+Dqb9804pTIx18trfxExrZi0glAhD1Uw65QYN7WpEqBH/ZD2xyaIY2E0FqenfQ/OfcQdkULH7VFqMVKM64uO9wGSPF2mb0XYjqnG7vw8MN82GevdMQsDeJxXzfpU+QfgD+J/moxMGvqpqLrWv7bHiyXGiG3VcT9bbPycP19wprIEhfqCYKqGCbEEKYUhfMq1Znq5MCW8AjEL6KcnALSqJAv+ZaYir1OpKwVTgQtZOaoSQAvVHJR7yWn8QkWQ7zm3+hN36nlElA5rxfOZdW+4vvpeO6Ege6hKfeiGD5zKtKKqHzirMt/jq7feO0pg0/tsk2/kGiFR5K4/k5LHO/7gj1SFbbooL133pUq10pKa 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)(346002)(366004)(396003)(39860400002)(136003)(376002)(230922051799003)(230273577357003)(230173577357003)(1800799012)(64100799003)(186009)(451199024)(41300700001)(26005)(31686004)(2616005)(36756003)(6486002)(316002)(54906003)(478600001)(53546011)(6506007)(38100700002)(6512007)(83380400001)(6666004)(110136005)(31696002)(66556008)(66946007)(5660300002)(66476007)(86362001)(2906002)(8676002)(44832011)(4326008)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aTgwY1hKeU43a2VpZXZHQThqTTdVLzBCWk5aS3RPQmJ5WjlYZmRCNWZsME8r?= =?utf-8?B?T1R4ZitScG42NW9wK0pSK09RRTBzSTJFaWRKMzNid0txdk1PNFdFeUNtZFFj?= =?utf-8?B?UHU1eHM1cUlYRll6THlMK3E3c08ySnE4R0JLYmxUWlpxQlFOQnZ0MzM0NmJp?= =?utf-8?B?VnpyVEVJOCtLOVREcFI4QkJzT2tVb0JKZHlLdHE4eW40R0hOWjUrZVZiSnN6?= =?utf-8?B?RUVReUd5dFlKckJlanhjb1ZOUFVlQjBKM2YrT0ZJWnY5VnBuWUIzeE8renlC?= =?utf-8?B?ZERrOEZJdkVCTkYvTVFKNE8rL3RLZmhFQVNJU3didlE4N2c4Tk9uRTA1YWJO?= =?utf-8?B?Wm5RdEk3VU9WZkE2TlJsV056dnB0bUhiUFdvZldzZnZNaU1CY1RDMnZyT3hC?= =?utf-8?B?QnhtYkVHRFNoT0tEWVp5d0xwblIvYUtmdkNta0I2cng2bHBpci8wQzRLN2NL?= =?utf-8?B?WHptZytCa2R3WldRcWIwRS9ZQ3lKTWNCY0tjckJ6c0t5M1JEL3BJV2lKcWly?= =?utf-8?B?UGY2SFRJMTZSckcycUlqbnZDd0pqVUJ6dWQwdmhkSy9lY0JrMGtCWDN6Yjhv?= =?utf-8?B?aEJReStSUVN2cEZuVm1xQUJFbmpBZ3NsckoxS1pTdXEveU0wWFZRdjJWUmo1?= =?utf-8?B?Tm9mdFZ6aXMxSnZEa2hnY2tuVC9IL2Y2KzV5L3dnck5sQ3BTTEM3UFBBekNn?= =?utf-8?B?dGtybElwc1BLb09NOFJNSVZ1ZEhEUCtPSjk4RTlYemtlNFlDajRGejlUS3Qw?= =?utf-8?B?NDJ0bzFvYjNGZGpXR0RCdVJRVzRxYmR1WWhGRmh0M3loM2Y1aHQyaVZVSHRJ?= =?utf-8?B?bkFuZ1I2NGgwU0NFWkJpelZqaXFxMmY3QzlycjBadXV1RlQzMW1VYXprMlFp?= =?utf-8?B?cGEyWVh5QW56L3g5ZExJejRyMTZOZHB2dFNKYWc0OFdPUHZ5blBkc3pBMHlz?= =?utf-8?B?MXRsWjVNNWxEcFBkVTM2NmFEcUdTSnhiT0RRYkIyaU1IV2NLNzE5OElmVE1K?= =?utf-8?B?WVBlUHhabjNUK2hDcWM4M050VnEvU09sTjI3MTN5SXNrbWQzNmxvZmlGQmVE?= =?utf-8?B?emxVS1V4MWdad05tMjdxc01ld1E3SmJpMVhTS2VLOENONzdKeVdpVzkxYzdp?= =?utf-8?B?d1ZIa2ErUWJSbDZob0JBK0hza0dZM0oxc202T21NUHNpUXVEZnFvYURFWjl2?= =?utf-8?B?d0EwWVIwaHoraUxvMlp3RDFtSWVnR1pON0JqcVpnSnRYUHZaUzRLOFdOSS9P?= =?utf-8?B?NEgrUFhIa0dsNFA1dThTNWE3T01lUXZFYTdCSENtT3pmTUY1Z2lyN1pUTjBp?= =?utf-8?B?T09CQ2gwZFIzSm1ibzJXZForNnlBcDVmYTBQb0k0TmFUWFNva3NkVEhWQWtJ?= =?utf-8?B?bXpaNXFrdjRPYlNudll2WUdHVEt1aVNYb1pWS3lxbWtCbHNmUFhRNG50eWx6?= =?utf-8?B?TTdnaHB3aWJScWx5eFVJR2xkN0FZbmduT0s2ei9adkY1aTloVVhpbFA4R3ds?= =?utf-8?B?aGJjcnJxYnIxSjN6QVByeUJKWjN4MjFmbDJUbWxhWmk1OFBnRU45bEtsVmJH?= =?utf-8?B?S2g2Q01uNTc3eFpuMnZTWXBVRmpIWVJkOVdrN3h1NTYyc2I0VzF5L25mSlZP?= =?utf-8?B?WTVDcTQwcWNvK1JWSlFaaTJxa2lXNCt5RUN4Y2JFa2FkTlZISE1rVlVDK3k1?= =?utf-8?B?R0UweE0wZ2xCWmUwWXZ6RFZFR3pCTUdocDlzUEtVSit4a3lBQ3hZQTgyek41?= =?utf-8?B?cnA1S0VQcExuZ0hvTWtHaGRLLzVld05zSXdYY2ZkK0R4OHpKaHJ4cGhzOWd6?= =?utf-8?B?WE1sMHc5RnhXbTV4bDArTGh3eXhTQk11c2cvKytrclhEakIzREVWT2RKbFNy?= =?utf-8?B?SmlMQmpDNjhrNys3SlRJbVRlWXc1UEQ0Z0NKclpiT0JzclhvZWk3aGlZS0FJ?= =?utf-8?B?TmZIelpvRjR2RW9pRlVCYWxWa2doTzVBY1BFLzk3L2NyUUFZNUZ1Ymd1U0JF?= =?utf-8?B?ajNKcnVZT0YzQmJzbnY3NzZCc28reXg2Uy9OSDdONFg4OS9RUlUwZ1Y1eUhV?= =?utf-8?B?VGdTSHMvdVpjMW5JeUMza1BNVjlPQUl4c2daMzZqeEtvTjJJczVsd0R2U2ZL?= =?utf-8?Q?TN4Q=3D?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd479ec7-ceb7-4fcf-fc3a-08dc20f0ce5d X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2024 17:36:21.0168 (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: ytNohR/B6jnNfrC1beOk/L0gCPbQtdhK0xxpjCVHWB9WUQkzweSQ4QIw4hgTutks X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4859 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 1/29/2024 1:38 PM, Dariusz Sosnowski wrote: > Hi all, > >> -----Original Message----- >> From: Dariusz Sosnowski >> Sent: Tuesday, January 23, 2024 12:37 >> To: Stephen Hemminger >> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ; >> Ferruh Yigit ; Andrew Rybchenko >> ; Ori Kam ; >> dev@dpdk.org >> Subject: RE: [RFC] ethdev: fast path async flow API >> >> Hi Stephen, >> >> Sorry for such a late response. >> >> From: Stephen Hemminger >> Sent: Thursday, January 4, 2024 02:08 >>> On Wed, 3 Jan 2024 19:14:49 +0000 >>> Dariusz Sosnowski wrote: >>>> In summary, in my opinion extending the async flow API with bulking >>> capabilities or exposing the queue directly to the application is not desirable. >>>> This proposal aims to reduce the I-cache overhead in async flow API >>>> by >>> reusing the existing design pattern in DPDK - fast path functions are >>> inlined to the application code and they call cached PMD callbacks. >>> >>> Inline needs to more discouraged in DPDK, because it only works if >>> application ends up building with DPDK from source. >>> It doesn't work for the Linux distro packaging model and symbol >>> versioning, etc. >> >> I understand the problem. In that case, I have a proposal. >> I had a chat with Thomas regarding this RFC, and he noticed that there are 2 >> separate changes proposed here: >> >> 1. Per-port callbacks for async flow API. >> - Moves specified callbacks to rte_flow_fp_ops struct and allow PMDs to >> register them dynamically. >> - Removes indirection at API level - no need to call rte_flow_ops_get(). >> - Removes checking if callbacks are defined - either the default DPDK callback >> is used or the one provided by PMD. >> 2. Make async flow API functions inlineable. >> >> Change (1) won't break ABI (existing callbacks in rte_flow_ops can be marked >> as deprecated for now and phased out later) and in my opinion is less >> controversial compared to change (2). >> >> I'll rerun the benchmarks for both changes separately to compare their >> benefits in isolation. >> This would allow us to decide if change (2) is worth the drawbacks it >> introduces. >> >> What do you think? > > I split the RFC into 2 parts: > > 1. Introduce per-port callbacks: > - Introduce rte_flow_fp_ops struct - holds callbacks for fast path calls, for each port. PMD registers callbacks through rte_flow_fp_ops_register(). > - Relevant rte_flow_async_* functions just pass arguments to fast path callbacks. Validation checks are done only if RTE_FLOW_DEBUG macro is defined. > - Biggest difference is the removal of callback access through rte_flow_get_ops(). > 2. Inline async flow API functions. > - Relevant rte_flow_async_* functions definitions are moved to rte_flow.h and made inlineable. > > Here are the results of the benchmark: > > | | Avg Insertion | Diff over baseline | Avg Deletion | Diff over baseline | > |-----------------------|---------------|--------------------|--------------|--------------------| > | baseline (v24.03-rc0) | 5855.4 | | 9026.8 | | > | applied (1) | 6384.2 | +528.8 (+9%) | 10054.2 | +1027.4 (+11.4%) | > | applied (2) | 6434.6 | +579.2 (+9.9%) | 10011.4 | +984.6 (+10.9%) | > > Results are in KFlows/sec. > The benchmark is continuously inserting and deleting 2M flow rules. > These rules match on IPv4 destination address and with a single action DROP. > Flow rules are inserted and deleted using a single flow queue. > > Change (2) improves insertion rate performance by ~1% compared to (1), but decreases deletion rate by ~0.5%. > Based on these results, I think we can say that making rte_flow_async_*() calls inlineable may not be worth it compared to the issues it causes. > > What do you all think about the results? > Hi Dariusz, As discussed before, converting APIs to static inline functions or exposing 'rte_eth_dev' has cons but with only applying first part above seems get rid of them with reasonable performance gain, so I think we can continue with this approach and continue to reviews. Most of the 'rte_flow_async_*' are already missing the function validity check, so having a default (dummy?) rte_flow_fp_ops for them seems even an improvement there. Only previously 'struct rte_flow_ops' was coming from drivers, ethdev layer doesn't need to maintain anything. But with 'rte_flow_fp_ops' struct, ethdev needs to store another array with fixed ('RTE_MAX_ETHPORTS') size which will be another blocker in the future to convert this fixed arrays to dynamically allocated arrays. For this, does it still help we add an a new field to "struct rte_eth_dev", like "struct rte_flow_ops *flow_ops", similar to 'dev_ops'? The indirection still will be there, but eliminate 'rte_flow_get_ops()' call and checks comes with it. If makes sense, is there a chance to experiment this and get some performance numbers with it?