From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 61106A04B1; Tue, 24 Nov 2020 13:56:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DBA58C912; Tue, 24 Nov 2020 13:56:31 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 4E688C910 for ; Tue, 24 Nov 2020 13:56:30 +0100 (CET) IronPort-SDR: eDMTU0xlk2KGKRme+Lrbj2pZnUxOMu0jP9PSFt5F4iJ/vPpoA13e22PyxDcAiKOCelrxavMh1r sTuRHgR3S+4Q== X-IronPort-AV: E=McAfee;i="6000,8403,9814"; a="172035329" X-IronPort-AV: E=Sophos;i="5.78,366,1599548400"; d="scan'208";a="172035329" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2020 04:56:28 -0800 IronPort-SDR: nAhPDRLgzaehhE7I2nMwSdnWKhZBFsaGrqPShEU+kH8wkB7Y1yfc0gocBuJwdeRWXbTtbOio1q BJJ4ZkeRAH3A== X-IronPort-AV: E=Sophos;i="5.78,366,1599548400"; d="scan'208";a="370359115" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.251.85.132]) ([10.251.85.132]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2020 04:56:26 -0800 To: Ori Kam , Andrew Rybchenko , Ray Kinsella , Neil Horman Cc: "dev@dpdk.org" , NBU-Contact-Thomas Monjalon References: <20201123134007.2870297-1-ferruh.yigit@intel.com> <148925d7-2ebd-fcbb-0d7c-6cbe3d15a6de@oktetlabs.ru> <6730d62f-6f18-0137-8e7f-140fa564c2d5@oktetlabs.ru> From: Ferruh Yigit Message-ID: Date: Tue, 24 Nov 2020 12:56:23 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] doc: announce flow API matching pattern struct changes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 11/24/2020 11:43 AM, Ori Kam wrote: > Hi > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Monday, November 23, 2020 5:51 PM >> Subject: Re: [PATCH] doc: announce flow API matching pattern struct changes >> >> On 11/23/2020 2:25 PM, Andrew Rybchenko wrote: >>> On 11/23/20 5:17 PM, Ferruh Yigit wrote: >>>> On 11/23/2020 1:50 PM, Andrew Rybchenko wrote: >>>>> On 11/23/20 4:40 PM, Ferruh Yigit wrote: >>>>>> Proposing to replace protocol header fields in the ``rte_flow_item_*`` >>>>>> structures with the protocol structs, like: >>>>>> >>>>>> Current ``struct rte_flow_item_eth``, >>>>>> >>>>>> struct rte_flow_item_eth { >>>>>>     struct rte_ether_addr dst; >>>>>>     struct rte_ether_addr src; >>>>>>     rte_be16_t type; >>>>>>     uint32_t has_vlan:1; >>>>>>     uint32_t reserved:31; >>>>>> } >>>>>> >>>>>> will become >>>>>> >>>>>> struct rte_flow_item_eth { >>>>>>     struct rte_ether_hdr hdr; >>>>>>     uint32_t has_vlan:1; >>>>>>     uint32_t reserved:31; >>>>>> } >>>>>> >>>>>> This is both for documenting the intention and to be sure >>>>>> ``rte_flow_item_*`` always starts with complete protocol header. >>>>>> >>>>>> Already many ``rte_flow_item_*`` structs implemented to have protocol >>>>>> struct, target is convert all to this usage. >>>>>> >>>>>> Signed-off-by: Ferruh Yigit >>>>> >>>>> Acked-by: Andrew Rybchenko >>>>> >>>>> a minor note below >>>>> >>>>>> --- >>>>>> Cc: Thomas Monjalon >>>>>> Cc: Andrew Rybchenko >>>>>> Cc: Ori Kam >>>>>> --- >>>>>>   doc/guides/rel_notes/deprecation.rst | 7 +++++++ >>>>>>   1 file changed, 7 insertions(+) >>>>>> >>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>>> b/doc/guides/rel_notes/deprecation.rst >>>>>> index 96986fabd598..a2fa0c196472 100644 >>>>>> --- a/doc/guides/rel_notes/deprecation.rst >>>>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>>>> @@ -88,6 +88,13 @@ Deprecation Notices >>>>>>     will be limited to maximum 256 queues. >>>>>>     Also compile time flag ``RTE_ETHDEV_QUEUE_STAT_CNTRS`` will be >>>>>> removed. >>>>>>   +* ethdev: The flow API matching pattern structures, ``struct >>>>>> rte_flow_item_*``, >>>>>> +  should start with relevant protocol header. >>>>>> +  Some matching pattern structures implements this by duplicating >>>>>> protocol header >>>>>> +  fields in the struct. To clarify the intention and to be sure >>>>>> protocol header >>>>>> +  is intact, will replace those fields with relevant protocol >>>>>> header struct. >>>>>> +  Target is v21.02 release and this should not change the ABI. >>>>>> + >>>>>>   * sched: To allow more traffic classes, flexible mapping of pipe >>>>>> queues to >>>>>>     traffic classes, and subport level configuration of pipes and >>>>>> queues >>>>>>     changes will be made to macros, data structures and API >>>>>> functions defined >>>>>> >>>>> >>>>> Just want to highlight that even API could be kept using >>>>> unnamed union for hdr and unnamed structure for existing >>>>> protocol header fields. >>>>> >>>> >>>> Then we may never clean the protocol header fields out of it, >>>> yes this will impact the user but I believe the impact is small and >>>> trivial, >>>> I prefer replacing fields with protocol struct. >>> >>> The problem that API breakages are bad and, for example, OvS uses these >>> fields. >>> >>> May be API breakage should be postponed to 21.11? >>> >> >> Agree but it is not as bad as ABI break, if user is already compiling their >> code, it is not too bad to adjust the struct for changes, and the changes are >> straightforward. >> > I'm not sure which is worse ABI or API, API is more straight forward but all apps must be modified, > while ABI is hidden and happens only in rare cases. > In a addition it may result in large number of changes (simple but large number) > >> But if, somehow, application needs to support multiple version of the DPDK it >> can be headache. >> > > Agree, > >> We may go with your suggestion until 21.11, and do the cleanup on 21.11, will >> it >> work? > +1 also when considering my next line, > > One more point to consider what happens to struct that are not according to spec, > for example mpls, geneve where the struct is different than the item. > At least for mpls & geneve, the ABI still looks same so change is still possible, but a few fields seems merged which means the change will require more updates in the user application and the drivers. Anyway, agree to postpone change to the 21.11. I will send a v2.