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 57D33A034F; Fri, 15 Oct 2021 18:26:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1CC5E410E0; Fri, 15 Oct 2021 18:26:58 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id CEE3C40042 for ; Fri, 15 Oct 2021 18:26:55 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10138"; a="227836686" X-IronPort-AV: E=Sophos;i="5.85,376,1624345200"; d="scan'208";a="227836686" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2021 09:26:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,376,1624345200"; d="scan'208";a="564380092" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by FMSMGA003.fm.intel.com with ESMTP; 15 Oct 2021 09:26:54 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 15 Oct 2021 09:26:54 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Fri, 15 Oct 2021 09:26:53 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) 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; Fri, 15 Oct 2021 09:26:53 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.109) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Fri, 15 Oct 2021 09:26:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LCcbKpuRHTwbV3rzpcADM7BZsDdtuBPyb5Vm4YUIionCUnqRkh88gMREvuIac/m6rJ4oQjRQIZ6q9Omxd4X6+tL3hZxhDZqDu8IoURp91CEElWqGTEJ/akiM+EjvzghqwAoZxJTGwg/Pnz8rJiYXtMjkin73alDj/ffL28WFUSKoz6+SioNL4RHRR5PXG41FGMroIiBl4ejjb3x6OcsqrNNTj/NfnYGMDTrKbpMncFR1ptUzYEQfGJLITVoXEzoXp11ed/ftCy7J37R/NOkdRdmjRQC7pgAwQKuk+SF1V4JklfyF3Q2u+wok6B8HfL3F54uUP4YeB1ibh5AIMxZZvA== 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=fdYm5TQT2jzHJBAVi6rOJXclRgNzlfbN1++FMaIaP0s=; b=N5fersZeiTfAooyXIZKb2WwWoitzlJ7MkoftN9snzXZcoXeYI6wrlWP2HQ6BUvlQ6vPtce5RuTOuTvcOv1sTHi/R2HARU4iqBLJOHKpVZZvvAGqZVB8kYHUGHCIgyA5Gs+W2/iqeIBrlc5PngssApv6wylDM76UgWP3NqiwI2FYZKTSBrfDjE3kLywbtroUkXRB5kGWLpkSAskT6jGz2fGlo9mr2g5qV1cqD0kjcv1qWl5WTeoyoOizPLqOTgAtPwu3Shd5MR+UkjEBM8yxhvMD5oZBzJr6AgRUWfsXJDdwkrEmmAXHSaySaQp2zTacXfgPDHYuma6M9EDj142N5Ng== 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=fdYm5TQT2jzHJBAVi6rOJXclRgNzlfbN1++FMaIaP0s=; b=nqvbKL6T+7yQRyexBTeQ3FB7Ixt/FSd0TwhiVoUmKShAmniqgVwpGO5iOBadsswTUoTMSJe/OEa8XQ/WfbtDzgSc6WzV1YlTQZchPD6S0xj/qG7SouwxnpGhKkcBL67G0aRnUOtcgh7hbTw6xpacKiuwLbRIA80IaPYAWQyDMYA= 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 PH0PR11MB5015.namprd11.prod.outlook.com (2603:10b6:510:39::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Fri, 15 Oct 2021 16:26:49 +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.017; Fri, 15 Oct 2021 16:26:49 +0000 Message-ID: <789becd1-24dc-b31c-6795-f1e4107a6266@intel.com> Date: Fri, 15 Oct 2021 17:26:42 +0100 Content-Language: en-US To: Dmitry Kozlyuk , "dev@dpdk.org" , Andrew Rybchenko , Ori Kam , Raslan Darawsheh CC: NBU-Contact-Thomas Monjalon , 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> From: Ferruh Yigit X-User: ferruhy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: DB6PR0202CA0043.eurprd02.prod.outlook.com (2603:10a6:4:a5::29) 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 DB6PR0202CA0043.eurprd02.prod.outlook.com (2603:10a6:4:a5::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14 via Frontend Transport; Fri, 15 Oct 2021 16:26:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8df8fbd9-d7c5-49e3-4b7b-08d98ff896ce X-MS-TrafficTypeDiagnostic: PH0PR11MB5015: 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: BWTONY6VSvyvEJPdVdlJ3gv8ghJlrpyHj+zmU6DyQNA6G+xY7fRI5EI6yksiiJNdE/9dHpk8vjGZmqGcN4Akitkcni8MSg+V6YpTyGTvbLY1EE3niIx5p77tG7bWcTxlzm1tdfPAecktn8OXzoJIcf7SDbRIL2QgpwdF8b8oTtezUjJBmL+8OF7lqu5XtX/SIW96zG0QEYzNFaduO3aCc50dbTjmehrWu7c3v1qys4NK+W7ENBAhNzG4z0nVLaRPC87uQSzeRYxRnyY/m05baguQyVwEoe4mx8zokebyqxODNl+Vp13Jzj/vt8G+URNGMCoHamIbSEvm+X330ZINBsZSE9ge7zCmzu4UUZVoMb+HJxXV9GKdhKcoXKw7yP+1QKimD2avvnFX95xcwxTxaMfWpiu+o3vJGQB1/P/2phP4r+dC7zZMjpT5rRD8r5ozULkB13PTxzUKLHTRtL3CSD9Rm+vgi8d2zf51A8gMl40SaT5ZS1zK6nKk4Z6PDhX3Mz6dzRBv36iIxwodl/UjVz4hRn2OHXn9CgOhXRazJQPpdMn/m2hG/8eWWh8Vy3mL5L4r0g3DuHzMyt3DN7OAreEzyIyEoqGr1dfrjFwcnFrXaDfCjBaWNPrgGTVw3d3fdloggYmh2Grw7uYJFo9ka5SUSOrZ2VvqvJWKMyN1sy+3QXt7WuTJ42patE7fRcEFgKItMkv0N2FGeVzHbF7INg== 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)(5660300002)(66476007)(38100700002)(508600001)(66946007)(31696002)(16576012)(66556008)(956004)(82960400001)(2616005)(44832011)(110136005)(86362001)(31686004)(4326008)(8936002)(6666004)(2906002)(6486002)(8676002)(26005)(53546011)(186003)(36756003)(54906003)(83380400001)(316002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?QkpZTGVxMDVtelBlRThEbW9TTDc4cFUrVDc4aUlwcklDL2hENFZHODlVQW5h?= =?utf-8?B?ZUtMMC9WOFBwVGFTeXFrWmRXbU9KQ053K1g2cU9Cbnd4U1dySFZiL2w5bUZr?= =?utf-8?B?WHRjak5EeERFeXZKUXlMd0E3ME9kRlJLTkZTbVBtRW1WS3hmaWo3MzhaaGRk?= =?utf-8?B?Q3h3bUM2WmFyQjNkc3lzMGM4VmdXS3o0dDMrSm9PUk1EZFBQc3IzVXRYVFRD?= =?utf-8?B?S3VsY2drbGt0YjhzalEvUGVvMHcyUzFmU3huQTZQSUY5c3BDNVd3WVRKSUlL?= =?utf-8?B?NWM4NGFNM3p0Wko1VWFUek9IWG5RUVBVRXVhVktKNVVWZkhxTE5wb1NBc3Fl?= =?utf-8?B?bUFKdTQ2RjdyUUV3Mk1DT29UMzZ2S3hwMGZKVUR2STJINWhlSFg2TG5INW9k?= =?utf-8?B?K3VuNU8xbmFYcHdVSWtYU0I3L2tHaU8zYUJGOFgwakd5NVhrWEE5bXdNbmhJ?= =?utf-8?B?VHdmdERaRm96Y3k0NU8xZ3BsUStUelpCbS9WM3J5QmVjQm9WWXBDYisxK1Fz?= =?utf-8?B?K3VhN29aSmF2NTBQUld0Sm5OMWZSaGhaR29PR25CQWpNRTVUck91aW9LSjJG?= =?utf-8?B?K1dVTkFWZ1p6d29xelhtWit1THpUcUJXUmFzc3Y1eU5mM00yNWxyWThTT2Rq?= =?utf-8?B?RjhnUHBvejFMRG9jbEd5Uk8zY0xYY0JrUll4ZXRSdld3UzJrNkZKZWxoa2N0?= =?utf-8?B?eFZ2Y21rSlRlUkZnRi80aERBeG9rRlNwNlQ0cXJZSk5OQWRQbnphSm9rTTRk?= =?utf-8?B?cXFSaURlVzNvTWZJa1JnZnZnenpIclVtZks5aU52dEo1S1RJQm1UUm1ITTEx?= =?utf-8?B?Qnh0WVZUT1NibzZEYjlUUWVJdkdLN1pwbUZsWUNOUDBBckgzTktXK3JSMTVX?= =?utf-8?B?c3M4MWlBZE02QTRWWjhVMGRuWGJtcUpRWmtNczRmQktRbituVjhTckcwU3R5?= =?utf-8?B?TXZISDFPU3ZyQXdRT2FDMmI4RXQ4SlAyRFdtTWxwVlBCMUEvTUNsVURoUDQ1?= =?utf-8?B?NXlHdkFNSzUxOW9wNlJrSmthbkhRWEw3UGp1TlFSVWlTU1R4Yktza09JbU02?= =?utf-8?B?Yy9QaDZPUDVjRXRVSmc1STlZc0dIRFEva2NPWFVDMW82STlKZFg5WHMzZnZj?= =?utf-8?B?aVVBUXNaekh6N1ZieTVsREZ3eExIN2VJaHN3cFQ0VWZia1pLYmhNL2lOV0JW?= =?utf-8?B?d2s2aFdWb3NiU1VVaUlBZ0N0VzEySzVjTlJxQTQwTUhaU3Qxa05XWWp0OHZU?= =?utf-8?B?RXh1LytLbHcySGtsUmw4c3N6QkhZNWJLMnRmb0xYSVArZFZ4bG5tUTdlZTJz?= =?utf-8?B?Z05sRXAyWFVweHl5Rk9RaElJbmIzUk94T1BFb1p0MUxmeXB0TFVMMEsrVkFT?= =?utf-8?B?eHV5eFRmZW1iZFJxVmNubWRFWjAxVy9FaEZvdUxjVzlTRXNBa1ErUWlpbC9h?= =?utf-8?B?MFo3d2VrVW5jZG9yMTJCOE9ncDhSQUpEcDdEMzR2TjJTeVlXVWQzRFdUbS9F?= =?utf-8?B?WWNnQnN5Tit5QzVyRTRpcEM3aURUeUV2TGNGTnBqVFhWR0I1TG91REdLbGxD?= =?utf-8?B?ZmRLOWpFc0pUUS9rSEZpQ2NHSWZnZlZta0pzcFhiR21CWWNUN0FLWlNrNE1l?= =?utf-8?B?RUFHc0Fta2Z2dGhib3pWSHIzc1phNFNWR0RnOEFTd1NaRXlwSVlaZWtUamJw?= =?utf-8?B?WVNtc2NyNWVJcTd3cU5tQVZzRnV6Z2JQNFNLMVZURkY5SksvalhQN2RxcHh6?= =?utf-8?Q?XC+fstoccIp3KwC9jo7YlHAz3POJb67CjXefa5/?= X-MS-Exchange-CrossTenant-Network-Message-Id: 8df8fbd9-d7c5-49e3-4b7b-08d98ff896ce X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2021 16:26:49.7356 (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: kL/UHWVJw2d1vPl83felKI/AstmDR1nENygU7J0f/OwAigE6iN9Za7/YOclXc5awVVuyMhQ0G3paoUKc46hQQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5015 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/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. > Result: no changes to PMDs are _immediately_ needed when such behavior > is documented. They can start advertising it whenever they like, > it's not even an RC2 task. Currently applications that relied on certain > behavior are non-portable anyway. > >> But having below list is good, if you will update all drivers than >> no need to have the 'unknown' state, but updating drivers may require >> driver maintainers ack which can take some time. > > If you agree with what I suggest above, there will be no urgency. > The list can be used to notify maintainers that they can enhance > their PMD user experience whenever they like. > >> Can you please clarify what is you plan according PMDs, will you update >> them all, or will you only update mlx5 in -rc2? >> And what is the exact plan for the -rc2 that you mention? > > mlx5 PMD will be updated with the patches from this series. > Regarding indirect actions: no other PMD needs an update. > Regarding flow rules: if the above suggestion is accepted, > no PMDs need to be updated urgently. >