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 6647CA053A; Wed, 5 Aug 2020 11:10:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 92BB11BFF7; Wed, 5 Aug 2020 11:10:20 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 9AF3A2BB5 for ; Wed, 5 Aug 2020 11:10:18 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id c6so1620324ilo.13 for ; Wed, 05 Aug 2020 02:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tbj3rR3PglIqgAF64vNNqN5tbB9ahARUDkb1DmolsuY=; b=sh7Yts0kksRl+Brq6KVDZ9PT4TpEKgXVoiUKz2PGGst8/2bs0gikbAXbq3PaTA2492 FCS2ApOMaOXu+Fv54rPqBLb/V4Kegnmu1UigwJx7ocHOLjnjQ6pe902tKd0Po5yjDz2H 2IW+fsRTQrTGzwPSC2OiuRlqoncgeeAhI3dB/3bWKqAux9qFOlFiGumLG7qhdtMW/Oa3 bpdlo+V+zUmcH9poXpmEAVGqgMiPWVw6qsW0bdIOiG6Ca/n5iC5aCrbNyfu7hVdPHrSq BrWij1pkvpMDGKtFupzCrUzR0nU9IXU2AnTSzFPcvT9n9pALR8AzqmUKU95/s5HZdXRl N4TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tbj3rR3PglIqgAF64vNNqN5tbB9ahARUDkb1DmolsuY=; b=ZoPA0m62uhvzgag2GLngT0U/5AlP0MBpaj0Nj6Yh81HZfQ/T+CCh51iJjb5D6Iy9oV sbAaQYcVK8IwB1Y4igW9iPMKQOVQ+1slL1TPNvdAfFBidFO0V97XASa6Sj0PVUAtxQOo IhyDZpMgOG0FvDNUINSwDsgDUxXx/fkfgXzaQqD2oZzfqbJuQWhjw5kFDQEZ3UX2jz9m SwCYJkjRmdh9EXrk2i9bbrvfDuSDM+zqSwGK7Gpu8ItojjfgKEvRNDRy10mNjrUSbSlS 9XCr6H7FT7uKFDpAT6F/rSQxZu0yvus+GW8mbOKzLaP8cwoAxpFstu8oS5xOH3WCe3ah obiw== X-Gm-Message-State: AOAM531mCiJihvqL2A8NmqF0c0TLfQd7/iWRwjQ8yqKrwjzwq/A8+hcO BuCAHiTskERs0u7cSNHyS7UHZ3kL1WCP3r8DwTE= X-Google-Smtp-Source: ABdhPJyGM8NCPmVSrEJT/5EkL1aZHdg0zHoRl5IZpRL43ODiFsJ0Cnx7one6yxnJ0RXp3ZMaq3W3Q3QC6MKbVSnAkxQ= X-Received: by 2002:a92:dcc8:: with SMTP id b8mr2800386ilr.60.1596618617869; Wed, 05 Aug 2020 02:10:17 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <216e9b9d-3a4e-8250-ffb6-4dc4a74c7867@ashroe.eu> From: Jerin Jacob Date: Wed, 5 Aug 2020 14:40:01 +0530 Message-ID: To: "Kinsella, Ray" Cc: Stephen Hemminger , Bruce Richardson , Pavan Nikhilesh , Jerin Jacob , Neil Horman , John McNamara , Marko Kovacevic , dpdk-dev , Thomas Monjalon , David Marchand Content-Type: text/plain; charset="UTF-8" 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, 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? How about 1) Public init functions to clear the params? 2) Different struct version for specific functions like http://mails.dpdk.org/archives/dev/2020-August/177357.html Or any other scheme in mind?