From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>
Subject: Re: [PATCH v1 2/8] bus: introduce opaque control
	framework
Date: Mon, 11 Dec 2017 13:43:59 +0100
Message-ID: <20171211124359.zhyeaveywobmobef@bidouze.vm.6wind.com>
References: <cover.1507796085.git.gaetan.rivet@6wind.com>
 <91106540c460d22dd23a30dc2903d7e238ff9a3b.1507796085.git.gaetan.rivet@6wind.com>
 <088de7d2-9bd4-4a49-44ba-9df9c52b72d1@nxp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: dev@dpdk.org
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com
 [209.85.128.194]) by dpdk.org (Postfix) with ESMTP id 2267F7D30
 for <dev@dpdk.org>; Mon, 11 Dec 2017 13:44:13 +0100 (CET)
Received: by mail-wr0-f194.google.com with SMTP id z18so17436137wrb.8
 for <dev@dpdk.org>; Mon, 11 Dec 2017 04:44:13 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <088de7d2-9bd4-4a49-44ba-9df9c52b72d1@nxp.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Dec 11, 2017 at 05:30:16PM +0530, Shreyansh Jain wrote:
> On Thursday 12 October 2017 01:48 PM, Gaetan Rivet wrote:
> > New configuration elements are added to the buses. They make the ABI
> > unstable and will continue to do so.
> > 
> > This new control scheme allows to add new bus operators without
> > breaking the ABI and by only expanding the API.
> > 
> > This helps having more stability in core EAL subsystems, while allowing
> > flexibility for future evolutions.
> > 
> > Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com>
> > ---
> >   lib/librte_eal/common/eal_common_bus.c  |  9 +++++++
> >   lib/librte_eal/common/include/rte_bus.h | 46 +++++++++++++++++++++++++++++++++
> >   2 files changed, 55 insertions(+)
> > 
> > diff --git a/lib/librte_eal/common/eal_common_bus.c b/lib/librte_eal/common/eal_common_bus.c
> > index 3c66a02..65d7229 100644
> > --- a/lib/librte_eal/common/eal_common_bus.c
> > +++ b/lib/librte_eal/common/eal_common_bus.c
> > @@ -42,6 +42,13 @@
> >   struct rte_bus_list rte_bus_list =
> >   	TAILQ_HEAD_INITIALIZER(rte_bus_list);
> > +static rte_bus_ctrl_t
> > +rte_bus_default_ctrl(enum rte_bus_ctrl_op op __rte_unused,
> > +		     enum rte_bus_ctrl_item item __rte_unused)
> > +{
> > +	return NULL;
> > +}
> > +
> >   void
> >   rte_bus_register(struct rte_bus *bus)
> >   {
> > @@ -53,6 +60,8 @@ rte_bus_register(struct rte_bus *bus)
> >   	RTE_VERIFY(bus->find_device);
> >   	/* Buses supporting driver plug also require unplug. */
> >   	RTE_VERIFY(!bus->plug || bus->unplug);
> > +	if (bus->ctrl == NULL)
> > +		bus->ctrl = &rte_bus_default_ctrl;
> >   	TAILQ_INSERT_TAIL(&rte_bus_list, bus, next);
> >   	RTE_LOG(DEBUG, EAL, "Registered [%s] bus.\n", bus->name);
> > diff --git a/lib/librte_eal/common/include/rte_bus.h b/lib/librte_eal/common/include/rte_bus.h
> > index 331d954..bd3c28e 100644
> > --- a/lib/librte_eal/common/include/rte_bus.h
> > +++ b/lib/librte_eal/common/include/rte_bus.h
> > @@ -183,6 +183,51 @@ struct rte_bus_conf {
> >   	enum rte_bus_probe_mode probe_mode; /**< Probe policy. */
> >   };
> > +/**
> > + * Bus configuration items.
> > + */
> > +enum rte_bus_ctrl_item {
> > +	RTE_BUS_CTRL_PROBE_MODE = 0,
> > +	RTE_BUS_CTRL_ITEM_MAX,
> > +};
> 
> I am assuming that a driver implementation can take more than ITEM_MAX
> control knobs. It is opaque to the library. Are we on same page?
> 
> For example, a bus driver can implement:
> 
> rte_bus_XXX_ctrl_item {
> 	<Leaving space for allowing rte_bus.h implementations>
> 	RTE_BUS_XYZ_KNOB_1 = 100,
> 	RTE_BUS_XYZ_KNOB_2,
> 	RTE_BUS_XYZ_KNOB_3,
> };
> 
> without the library knowing or restricting the API to RTE_BUS_CTRL_ITEM_MAX.
> 
> I see that in your code for PCI (Patch 5/8: pci_ctrl) you have restricted
> the control knob to RTE_BUS_CTRL_ITEM_MAX.
> I hope that such restrictions would not float to library layer.
> 
> If we are on same page, should this be documented as a code comment
> somewhere?
> if not, do you think what I am stating makes sense?
> 

I see what you mean, but I'm not sure it would be a good thing.
Actually, I think proposing this ITEM_MAX was a mistake.

Regarding the specific bus knobs:

- If a single bus needs this knob, then it would be better for the dev
  to add it as part of the bus' public API, following the correct
  library versioning processes. This would not break this bus control
  structure ABI.

- If more than one bus implement this knob, then it should be proposed
  as part of the library API. Buses adding this new knob would break
  their ABI, other buses would be left untouched.

This makes me realize that proposing this ITEM_MAX value is not good to
the intended purpose of this patchset:

- If a bus implementation use a reference to ITEM_MAX, then the control
  structure ABI would be broken by any new control knob added, even if the
  bus does not implement it. Granted, it would not break the driver
  structure itself, but still. My PCI implementation is thus incorrect.

Therefore I think that it would be best to remove this ITEM_MAX altogether,
forcing bus developpers to use other ways that would not break their
ABIs every other release.

-- 
Gaëtan Rivet
6WIND