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 98564A0C43; Mon, 18 Oct 2021 10:42:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B88C40141; Mon, 18 Oct 2021 10:42:47 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id D7F0C4003C for ; Mon, 18 Oct 2021 10:42:43 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10140"; a="228150044" X-IronPort-AV: E=Sophos;i="5.85,381,1624345200"; d="scan'208";a="228150044" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Oct 2021 01:42:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,381,1624345200"; d="scan'208";a="530203403" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by fmsmga008.fm.intel.com with ESMTP; 18 Oct 2021 01:42:42 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 18 Oct 2021 01:42:42 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 18 Oct 2021 01:42:42 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.171) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 18 Oct 2021 01:42:41 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GEMDh/fPQoiELLJBmVfH758nOKRsboCdsqG3Sayx+yYwAmLjQQj8d3PgywwKfgG7VL2oRLGAU7Abr4LkSOH5SGhjV198mnXyCvwJY34MD0jHZR0UyonwP6SuxdmSGVyK+mlziVUea7zJrMaWVGj4t2sjd3/S/taVfxIBQWJKSzPekziT9NKvBx3+Hyhi7kYH+HP9OwD84ldBb42xwvqSJJTah1JLkYzMXt7J1azkbAaua2uWQyadeUk/Z+9Aa1QFUMPyPePsTpHIIDgcNaTTcC+aMe3rfxMTn0UAtwYOcSyFG/il3hawu7VxnIGmeMeiZlmGVAleBXJSM/VCVhGlhQ== 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=VUGCsL/FzS+ef9DX7wjT6Pm/ky4ekl06X4dSicQy+8Y=; b=gJ08KwIJw6n8aR9ewQx72ztdS8QekAkcx/h//1O05DXrJuQIOqfbJxzx+LYla2p+84bb6aJUbBXdjInpCmsUfqOXs510wJcTQhA4yjZxZ2vy+SEZT6U8RQKaZewHt0N7p1b5ajQB30fKIWSYAK0QAbpY7rRQ3JUCCSGvfHhjh+v3smAtaBDBKbOSKb3AGfGfl1e+pV/D0N59FOu3BDZiacd3k6vaKK1/HVeoRiToVkIHWi+NJWed0ZHzzr1p4ZreMoZxBtZNh2sIGC8C0SsbhUXtov387yEF2pppZqgTyLL9QxsIDpsAuDkr0nOPl+8H4nK+Y4bMJVV5sGE0nPtC2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VUGCsL/FzS+ef9DX7wjT6Pm/ky4ekl06X4dSicQy+8Y=; b=Qi6+kZRt77LaVOUF16+sMqPUwsuEGdo3aYIB0TpMF2N7x0Qu87Gx1GFXmywuAhg7B2tBcc1FcKyBKSVZaxwFrH5VPAkOLwdBcCe5JJTh3ekIH2TABfGjg8Ee4W4udD9gmOXg+m1edRrBkGdvLmTQ6O/Ooj3Bj5JGwVxMwSM/i/I= Authentication-Results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5045.namprd11.prod.outlook.com (2603:10b6:510:3f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Mon, 18 Oct 2021 08:42:33 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c%5]) with mapi id 15.20.4608.018; Mon, 18 Oct 2021 08:42:33 +0000 Message-ID: <6e148fd8-c7b9-dd90-d286-a54ff0faf713@intel.com> Date: Mon, 18 Oct 2021 09:42:26 +0100 Content-Language: en-US To: Dmitry Kozlyuk , "dev@dpdk.org" , Andrew Rybchenko , Ori Kam , Raslan Darawsheh , NBU-Contact-Thomas Monjalon CC: Qi Zhang , "jerinj@marvell.com" , Maxime Coquelin References: <20211005005216.2427489-1-dkozlyuk@nvidia.com> <20211005005216.2427489-3-dkozlyuk@nvidia.com> <9a9ab2b5-89d1-1653-9022-ebf1b8a86902@intel.com> <0f16daab-6040-2973-03f3-8bc4e954c84e@intel.com> <789becd1-24dc-b31c-6795-f1e4107a6266@intel.com> From: Ferruh Yigit X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6PR0402CA0020.eurprd04.prod.outlook.com (2603:10a6:4:91::30) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6PR0402CA0020.eurprd04.prod.outlook.com (2603:10a6:4:91::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14 via Frontend Transport; Mon, 18 Oct 2021 08:42:31 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5a533c9d-4110-45c4-90c1-08d992133a91 X-MS-TrafficTypeDiagnostic: PH0PR11MB5045: X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-MS-Exchange-Transport-Forked: True 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: 9ffDCAUEonBsyF8EEM25Bm4p5foD5gnrJpGNvDVlQhJ/5KXQ36eOdZBSv1oklbdU38MSPliuSOSHxVjs6P9pmQqE+ZvCirQfJ6GiVP9Nns2ACdkefVTEYgg5IE1kHfv0ApNv/xK0dxQ262eRBZX0HmgiPe/a02tF2yBtgD9cPtn1iPqrMxHVZnXscAFZaorBCwZfwwD0Dlm0X4kp57BverpbG4azQ79mLPlEojOdP3uDBWV9u6/Cpas5IzGE57BhThnUnTQ2V5FHUZsjybg14vdbCecByeCQ457C3jV2+2Q8FNYqKQDSCqubB4QdNfFIow/f6DEUlQTS5dlyNLgVr8g+NOYbnL5c8b43rjYGlT71wsFSPMdHqJCRGNLVmxp2EJo6BQxlKM2lgrqbl0i4hL4EV0/1FJGFYtSA2atYGFRFkokGlcig6KeAs9sdy673wRiT4S5Usn4ctLrGzpDnkdIcM8jFtRnjY1RS4gifpl2OKkM9SJ2B3eMBsyghmEG3SJvSJiSpbxMLVHBkoqCsXaSJOaFgIM34w7FfEtCnAAFo+OdSnUBTBWJ5Vpd05RYhI+4Glv2/rKyP9pFlXJXJXraA+oA1hyaDaK8+nAPvPBOx4yOy854i+GZVLg+IW7toos9ukgDTsr3nTDEb4Hwcer9TsHBobZBmD3kGdpCFB7bLNrAuJ7DB/xDH/G73dxsN7w+bXgDufvqRCQX0UQNdaA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(186003)(2906002)(110136005)(38100700002)(31686004)(44832011)(16576012)(4326008)(86362001)(66556008)(5660300002)(6666004)(8936002)(31696002)(53546011)(26005)(8676002)(6486002)(83380400001)(316002)(66946007)(36756003)(82960400001)(2616005)(54906003)(956004)(66476007)(508600001)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NlRrYXowODZVY0t4TTlSWXVpRGF0MUlBVGpzcDJuZkJuZGFWNFNIc2swTzh1?= =?utf-8?B?cEw5anA3VzBpTHcrZm05MzdldDZEaEdJQlhicXpTRTBod1Y3aW0zMXpweWlI?= =?utf-8?B?V3VNK0dwUmxyUXI4ajRYdzlVb3Y1a09ib01JRVhzajlERzFMNHBzQlJwREp4?= =?utf-8?B?UlFJWVVKbUx2anVmT1UyMFRFWTZ1ZU11emQ4elJpMGNXTDV4cytYTXBNVi9S?= =?utf-8?B?OVluSmR4QWgyZXRwYTlLdmRDMkdRamp4dWszNWppSHV2R2hSY1dUZ05BNmxZ?= =?utf-8?B?VWtQOGozM0NNdlZhNjFxeGQzWWVuQXYwbUV2WDF4TXg2RnVWbVhHWnpLMzVm?= =?utf-8?B?c0had1QrQWVPcVFuRVVNakJvalRXcWFjUksxV3NQdmZLTTNpL09UZGJGRFlD?= =?utf-8?B?Wlh5U0hWVDY3VFdaMWhQQmdMcUgrb1BFUHlybHhwZVltSndZcTZRcXFMZWpy?= =?utf-8?B?Sk5NSEMvMzAwK2h1MUFnak01Szh3WnRtQVpwQit3dnN5dWpzdXZsUlRlVGxl?= =?utf-8?B?NVJFZi9FQ2pqMk1LNUJqVGJzcXFHSjVFN29PNS9oeFprNFNidS8vc2NweCtR?= =?utf-8?B?Mk4rQjJ0c082anZJdVBsOWFLM29QdDAyMU5lQUU3aDZkdS83OFhPRmc0clFy?= =?utf-8?B?eFFqOFllcEQrdDdNaVEvOERBQUoyU2dscU1zY1pyMzVQeVhoZ2Qyc1RWeE5Q?= =?utf-8?B?R01VbEtQTGJOdWtCQzBleFNMTkpaMGdUWlp6NzN1MEY1WE5WbzFFeXFrelo0?= =?utf-8?B?RWI5VmpuME9SNjdLcVU3ZnRTNUU3YW9Kb3YrSkZCRHd1dHNsanhoL1gxd3BJ?= =?utf-8?B?YytkQ2dBa29PeTBVQktaSWRJa09PanNuK2JEL0xTMmZ4MFFHTmIzVDFmSHRW?= =?utf-8?B?clc1THNkTnJOaXl1dEExVnhkdW5heXYwdjlYU3Vyeis2Yy8wOEpaOXJHMzY3?= =?utf-8?B?NGlLbWVqYjVFWFcyZnFNblBraHZqZHZ4U1c3SVN6QUFueGpoLzZiQ3ExS0lR?= =?utf-8?B?M1pkYjJwWEsydnNSb0hLNkVWTGpFclYzaXVrbGV3Q2RURkg3ZE4zaURHdmYr?= =?utf-8?B?by9MRzZmTkd5MkNGVFVFbFVveVNWU01NRUhlQ3g3ZXFFRXNLMkpqOUl1bWpy?= =?utf-8?B?eUZsbUIvUHdMTlJUdlhsTkd3ME9rSEFGTEdmbkh2M0hCYUxDOVlEUEFzdENl?= =?utf-8?B?TnoxNHRQQis0M0NYQWVmbTM5dmNDTFVUbyszVTFrNzZGdVRrdVVWdk1IREcy?= =?utf-8?B?cElFcnVQWUNqRlNMTnBBMUN1ODhvaXAvVHlYNmJENjF5UWo4VHQ3bGFkd2Jh?= =?utf-8?B?UmZzU3paaHJ2T1dZeWtTdHNvRDZjaklzK3g4Nm5pMGZwK0xaTjI0RmpGRWtE?= =?utf-8?B?WlJaL3p3T2dEWkgwL2llRjJCemhUVEpWTWdwKzBJUTlFZUIvNGg2eUtDdzYr?= =?utf-8?B?VSszaTVIdmYrZ2M0Z2hxNWdDbFFKWHpCdFNYeC9vMisyYktSOTZLVS9MTlpV?= =?utf-8?B?SlB4ZmhaeSt2Uk1mQ2tvQmR6a05mb1h2SDRGVzhmRlNQY3hqUEdac0tBUmFQ?= =?utf-8?B?VmlVTjZtbFRSMjg4Y0xQcG92ZlRpYk9ZWDNOaEIxSVY5cWVoNDFzUWZkUnUv?= =?utf-8?B?b0ZuYlNDdWFqYkNlRUdycXBOYWdWNHBxSis4Y0pxeERsN0ROTW45MFNVTGli?= =?utf-8?B?b2RLV0pCeEg1MExtdEF0RmlMeXVSL21QQTJxTFhzb2t2SFo1Z1dhTkNFaWtq?= =?utf-8?Q?ETCqnsdce6e6dpJYknov6w93jVmWjfKkGzOE0zm?= X-MS-Exchange-CrossTenant-Network-Message-Id: 5a533c9d-4110-45c4-90c1-08d992133a91 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Oct 2021 08:42:33.7374 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: X3BmPkImgKetg7hxuMN5RfOP9hyehiDiK6cFtAS14pBzItaIoFvfGMh35/q+7OvrHoADbn3Mx0ltWIi0XtPrpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5045 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add capability to keep shared objects on restart 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" On 10/16/2021 9:32 PM, Dmitry Kozlyuk wrote: >> -----Original Message----- >> From: Ferruh Yigit >> Sent: 15 октября 2021 г. 19:27 >> To: Dmitry Kozlyuk ; dev@dpdk.org; Andrew Rybchenko >> ; Ori Kam ; Raslan >> Darawsheh >> Cc: NBU-Contact-Thomas Monjalon ; Qi Zhang >> ; jerinj@marvell.com; Maxime Coquelin >> >> Subject: Re: [PATCH 2/5] ethdev: add capability to keep shared objects on >> restart >> >> External email: Use caution opening links or attachments >> >> >> On 10/15/2021 1:35 PM, Dmitry Kozlyuk wrote: >>>> -----Original Message----- >>>> From: Ferruh Yigit >>>> [...] >>>>> Introducing UNKNOWN state seems wrong to me. >>>>> What should an application do when it is reported? >>>>> Now there's just no way to learn how the PMD behaves, >>>>> but if it provides a response, it can't be "I don't know what I do". >>>>> >>>> >>>> I agree 'unknown' state is not ideal, but my intentions is prevent >>>> drivers that not implemented this new feature report wrong capability. >>>> >>>> Without capability, application already doesn't know how underlying >>>> PMD behaves, so this is by default 'unknown' state. >>>> I suggest keeping that state until driver explicitly updates its state >>>> to the correct value. >>> >>> My concern is that when all the drivers are changed to report a proper >>> capability, UNKNOWN remains in the API meaning "there's a bug in DPDK". >>> >> >> When all drivers are changed, of course we can remove the 'unknown' flag. >> >>> Instead of UNKNOWN response we can declare that rte_flow_flush() >>> must be called unless the application wants to keep the rules >>> and has made sure it's possible, or the behavior is undefined. >>> (Can be viewed as "UNKNOWN by default", but is simpler.) >>> This way neither UNKNOWN state is needed, >>> nor the bit saying the flow rules are flushed. >>> Here is why, let's consider KEEP and FLUSH combinations: >>> >>> (1) FLUSH=0, KEEP=0 is equivalent to UNKNOWN, i.e. the application >>> must explicitly flush the rules itself >>> in order to get deterministic behavior. >>> (2) FLUSH=1, KEEP=0 means PMD flushes all rules on the device stop. >>> (3) FLUSH=0, KEEP=1 means PMD can keep at least some rules, >>> exact support must be checked with >> rte_flow_create() >>> when the device is stopped. >>> (4) FLUSH=1, KEEP=1 is forbidden. >>> >> >> What is 'FLUSH' here? Are you proposing a new capability? >> >>> If the application doesn't need the PMD to keep flow rules, >>> it can as well flush them always before the device stop >>> regardless of whether the driver does it automatically or not. >>> It's even simpler and probably as efficient. Testpmd does this. >>> If the application wants to take advantage of rule-keeping ability, >>> it just tests the KEEP bit. If it is unset that's the previous case, >>> application should call rte_flow_flush() before the device stop to be >> sure. >>> Otherwise, the application can test capability to keep flow rule kinds >>> it is interested in (see my reply to Andrew). >>> >> >> Overall this is an optimization, application can workaround without this >> capability. >> >> If driver doesn't set KEEP capability, it is not clear what does it >> mean, driver doesn't keep rules or driver is not updated yet. >> I suggest to update comment to clarify the meaning of the missing KEEP >> flag. >> >> And unless we have two explicit status flags application can never be >> sure that driver doesn't keep rules after stop. I am don't know if >> application wants to know this. >> >> Other concern is how PMD maintainers will know that there is something >> to update here, I am sure many driver maintainers won't even be aware of >> this, your patch doesn't even cc them. Your approach feels like you are >> thinking only single PMD and ignore rest. >> >> My intention was to have a way to follow drivers that is not updated, >> by marking them with UNKNOWN flag. But this also doesn't work with new >> drivers, they may forget setting capability. >> >> >> What about following: >> 1) Clarify KEEP flag meaning: >> having KEEP: flow rules are kept after stop >> missing KEEP: unknown behavior >> >> 2) Mark all PMDs with useless flag: >> dev_capa &= ~KEEP >> Maintainer can remove or update this later, and we can easily track it. > > Item 1) is almost what I did in v2. The difference (or clarification) is that > if the bit is set, it doesn't mean that all rules are kept. > It allows the PMD to not support keeping some kinds of rules. > Please see the doc update about how the kind is defined > and how the application can test what is unsupported. > > This complication is needed so that if a PMD cannot keep some exotic kind of rules, > it is not forced to remove the capability completely, > blocking optimizations even if the application doesn't use problematic rule kinds. > It makes the capability future-proof. > > The second flag (FLUSH) would not be of much help. > Consider it is not set, but the PMD can keep some kinds of rules. > The application still needs to test all the kinds it needs. > But it needs to do the same if the KEEP bit is set. > Only if it is set the application can skip the tests and rte_flow_flush(), > but these optimizations are small compared to keeping the rules itself. > > Item 2) needs not to be done, because the absence of the bit is *the* useless value: > it means the unspecified same behavior as it is presently. > It is worth noting that currently any application that relies on the PMD > to keep or flush the rules is non-portable, because PMD is allowed to do anything. > To get a reliable behavior application must explicitly clear the rules. > > Regarding you concern about maintainers forgetting to update PMDs, > I think there are better task-tracking tools then constants in the code > (the authors of golang's context.TODO may disagree :) > Hi Dmitry, This is a valid concern, and adding code to the drivers proved that it works. There are multiple authors updating the ethdev layer and expecting PMD maintainers will do required changes. For your case you are updating the PMD you concern but how other PMD maintainers will even be aware that there is something to change in their PMD? By your change you are putting some responsibility to other maintainers, without even cc'ing them. And it is for sure they are not reading all emails in the mail list, they can't. Task-tracking is an option, it the past I tried to upstream some todo doc for PMDs. But I can see the additional maintenance cost to trace features from a central point, comparing the distributing it to PMDS (adding code to PMDs). I think best method is whoever doing the ethdev layer do the relevant change in the PMDs, but has the obvious problem that not able to know enough about the PMDs to update them. We have used the following option, and it worked in the past: - When an ethdev feature require change in PMDs, ehtdev supports both new and old method - PMDs set a flag by default to request old method, so there is no update in the PMD default behavior - When PMD does the required changes, it removes the flag - This lets me (or other maintainer), to trace the update status and ping relevant maintainers - When all PMDs updated, ethdev support for old method removed - This method allows PMD maintainers do the change on their own time