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 DD6BBA052B; Thu, 6 Aug 2020 03:00:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1648A2B87; Thu, 6 Aug 2020 03:00:01 +0200 (CEST) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 555A51DBF for ; Thu, 6 Aug 2020 02:59:59 +0200 (CEST) Received: by mail-pf1-f196.google.com with SMTP id s26so23998418pfm.4 for ; Wed, 05 Aug 2020 17:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=K9HlNBlgRqviRUAc5X5/3WFFoszBdnH2SLCPUgYCjd4=; b=Kv2yv4naZsOMjeQe+Hrz3OPiEGckwy4xqAk2qGeCDeW+vAKkCVjb+Lc/H0HP2yJnia rC8YG1Jkv53xFrct1yokZuVJd2hujbNHvN0N01itNHT+NXND6Qd2aHsFpWOFoNfDyiNu AK9MpkxL799gwwDqtIqKurOZkHQk32GpOmrlVVlOc9nZDVRfuYmGf8us2fNCgorZbOZa UPfDS/8O8PSewxaKyKmUrIsUDKB22+5PomJqsBVr8cChmAjg+3ydJXYBciLm54BdeQFe D6Sd8qsd5/IOvE4y5OU2W1BNI/fugb5Z6B/psSfmOpBqq2MNhj6Pq4O/aDMTNhQtuqKF bP2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=K9HlNBlgRqviRUAc5X5/3WFFoszBdnH2SLCPUgYCjd4=; b=q0bzrCJNFNXa1WV0dVEwcGwhHrP3Z7quv4BReZlNm0Fd8WTU1HWIc8OXZ87jPdA7Lh begCt4cHI4hoFhXeZS2uakTCvy9siDLDOspPztZnIqhdwFs7QxpSc2AD9zJh376rtsWJ CTxhw37pSOC8N70QhQ8P+UBLtFjxVkkSfmjAgNnIFq1tj/2PesW1U84HSIDnwdBnT4Yu f9kbsQiuD1yZYSlmzFSz8N4ipbUMm1u2i2/rooiXJiTi1iAdLlh9XF4D9eVlIXjcHTin YhNP9k5FKU/vh3f8lUg6FoB6lTzfUbu41uvWG/WPjQXsM0TkuTGFXmoYmIlHDOwp/Iyf HLIA== X-Gm-Message-State: AOAM531OvtGSJ18pUQHzSZJssSijQ2lojYrwmo180H9ukEMOJCUEuCM3 IIr+F0QXe9Tee5mTEPfEho0wRg== X-Google-Smtp-Source: ABdhPJzHUZUW9hXxzgIAJge6g4Y+iO4Ioi1PJJ+QpDKDvMtEXy1AwW2sQ9cHs3AT/Ps36AuLO6ZEbg== X-Received: by 2002:a62:3684:: with SMTP id d126mr5836706pfa.234.1596675598328; Wed, 05 Aug 2020 17:59:58 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u29sm5675534pfl.180.2020.08.05.17.59.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2020 17:59:58 -0700 (PDT) Date: Wed, 5 Aug 2020 17:59:50 -0700 From: Stephen Hemminger To: Jerin Jacob Cc: "Kinsella, Ray" , Bruce Richardson , Pavan Nikhilesh , Jerin Jacob , Neil Horman , John McNamara , Marko Kovacevic , dpdk-dev , Thomas Monjalon , David Marchand Message-ID: <20200805175950.3888ef11@hermes.lan> In-Reply-To: References: <20200802105137.1666-1-pbhagavatula@marvell.com> <20200803072903.1209-1-pbhagavatula@marvell.com> <20200804104153.GA1464@bricha3-MOBL.ger.corp.intel.com> <20200804092007.54bf76f3@hermes.lan> <216e9b9d-3a4e-8250-ffb6-4dc4a74c7867@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] doc: add reserve fields to eventdev public structures 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 Wed, 5 Aug 2020 14:40:01 +0530 Jerin Jacob wrote: > On Wed, Aug 5, 2020 at 2:16 PM Kinsella, Ray wrote: > > > > > > > > On 04/08/2020 17:20, Stephen Hemminger wrote: > > > On Tue, 4 Aug 2020 11:41:53 +0100 > > > Bruce Richardson wrote: > > > > > >> On Mon, Aug 03, 2020 at 12:59:03PM +0530, pbhagavatula@marvell.com wrote: > > >>> From: Pavan Nikhilesh > > >>> > > >>> Add 64 byte padding at the end of event device public structure to allow > > >>> future extensions. > > >>> > > >>> Signed-off-by: Pavan Nikhilesh > > >>> Acked-by: Jerin Jacob > > >>> --- > > >>> v2 Changes: > > >>> - Modify commit title. > > >>> - Add patch reference to doc. > > >>> > > >>> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++ > > >>> 1 file changed, 11 insertions(+) > > >>> > > >>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > > >>> index ea4cfa7a4..ec5db68e9 100644 > > >>> --- a/doc/guides/rel_notes/deprecation.rst > > >>> +++ b/doc/guides/rel_notes/deprecation.rst > > >>> @@ -151,3 +151,14 @@ Deprecation Notices > > >>> Python 2 support will be completely removed in 20.11. > > >>> In 20.08, explicit deprecation warnings will be displayed when running > > >>> scripts with Python 2. > > >>> + > > >>> +* eventdev: A 64 byte padding is added at the end of the following structures > > >>> + in event device library to support future extensions: > > >>> + ``rte_event_crypto_adapter_conf``, ``rte_event_eth_rx_adapter_conf``, > > >>> + ``rte_event_eth_rx_adapter_queue_conf``, ``rte_event_eth_tx_adapter_conf``, > > >>> + ``rte_event_timer_adapter_conf``, ``rte_event_timer_adapter_info``, > > >>> + ``rte_event_dev_info``, ``rte_event_dev_config``, ``rte_event_queue_conf``, > > >>> + ``rte_event_port_conf``, ``rte_event_timer_adapter``, > > >>> + ``rte_event_timer_adapter_data``. > > >>> + Reference: > > >>> + http://patches.dpdk.org/project/dpdk/list/?series=10728&archive=both&state=* > > >>> -- > > >> > > >> I don't like this idea of adding lots of padding to the ends of these > > >> structures. For some structures, such as the public arrays for devices it > > >> may be necessary, but for all the conf structures passed as parameters to > > >> functions I think we can do better. Since these structures are passed by > > >> the user to various functions, function versioning can be used to ensure > > >> that the correct function in eventdev is always called. From there to the > > >> individual PMDs, we can implement ABI compatibility by either: > > >> 1. including the length of the struct as a parameter to the driver. (This is > > >> a bit similar to my proposal for rawdev [1]) > > >> 2. including the ABI version as a parameter to the driver. > > >> > > >> Regards > > >> /Bruce > > >> > > >> [1] http://inbox.dpdk.org/dev/?q=enhance+rawdev+APIs > > > > > > This is a bad idea. > > > > > > Reserved fields won't work because nothing requires that the application > > > zero them. You can't start using them later because the application > > > may put uninitialized or junk data there. > > > > > > > +1, to Stephens comments. > > Since the problem is not specific to one substem, if we need to add a > field in config structures, > What will the expected way of handling across the DPDK? If you need fields go through the normal enhancement process, and get it reviewed and put them in a major release milestone. Sorry, there is no free lunch by adding reserved fields. Look up YAGNI