Re: [dpdk-dev] [PATCH v2 01/11] bus: add bus iterator to find a particular bus

["Gaëtan Rivet" <gaetan.rivet@6wind.com>]

On Thu, Jun 08, 2017 at 04:34:50AM +0000, Shreyansh Jain wrote:
> Hello Gaëtan,
> 
> > -----Original Message-----
> > From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com]
> > Sent: Wednesday, June 07, 2017 6:58 PM
> > To: Shreyansh Jain <shreyansh.jain@nxp.com>
> > Cc: dev@dpdk.org; Jan Blunck <jblunck@infradead.org>
> > Subject: Re: [PATCH v2 01/11] bus: add bus iterator to find a particular bus
> > 
> > On Wed, Jun 07, 2017 at 12:36:53PM +0530, Shreyansh Jain wrote:
> > > Hello Gaetan,
> > >
> > > On Wednesday 31 May 2017 06:47 PM, Gaetan Rivet wrote:
> > > >From: Jan Blunck <jblunck@infradead.org>
> > > >
> > > >Signed-off-by: Jan Blunck <jblunck@infradead.org>
> > > >Signed-off-by: Gaetan Rivet <gaetan.rivet@6wind.com>
> > > >---
> > > >  lib/librte_eal/bsdapp/eal/rte_eal_version.map   |  1 +
> > > >  lib/librte_eal/common/eal_common_bus.c          | 13 ++++++++++
> > > >  lib/librte_eal/common/include/rte_bus.h         | 32
> > +++++++++++++++++++++++++
> > > >  lib/librte_eal/linuxapp/eal/rte_eal_version.map |  1 +
> > > >  4 files changed, 47 insertions(+)
> > > >
> > > >diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > >index 2e48a73..ed09ab2 100644
> > > >--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > >+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
> > > >@@ -162,6 +162,7 @@ DPDK_17.02 {
> > > >  DPDK_17.05 {
> > > >  	global:
> > > >+	rte_bus_find;
> > > >  	rte_cpu_is_supported;
> > > >  	rte_log_dump;
> > > >  	rte_log_register;
> > > >diff --git a/lib/librte_eal/common/eal_common_bus.c
> > b/lib/librte_eal/common/eal_common_bus.c
> > > >index 8f9baf8..68f70d0 100644
> > > >--- a/lib/librte_eal/common/eal_common_bus.c
> > > >+++ b/lib/librte_eal/common/eal_common_bus.c
> > > >@@ -145,3 +145,16 @@ rte_bus_dump(FILE *f)
> > > >  		}
> > > >  	}
> > > >  }
> > > >+
> > > >+struct rte_bus *
> > > >+rte_bus_find(rte_bus_match_t match, const void *data)
> > > >+{
> > > >+	struct rte_bus *bus = NULL;
> > > >+
> > > >+	TAILQ_FOREACH(bus, &rte_bus_list, next) {
> > > >+		if (match(bus, data))
> > > >+			break;
> > > >+	}
> > > >+
> > > >+	return bus;
> > > >+}
> > > >diff --git a/lib/librte_eal/common/include/rte_bus.h
> > b/lib/librte_eal/common/include/rte_bus.h
> > > >index 7c36969..006feca 100644
> > > >--- a/lib/librte_eal/common/include/rte_bus.h
> > > >+++ b/lib/librte_eal/common/include/rte_bus.h
> > > >@@ -141,6 +141,38 @@ int rte_bus_probe(void);
> > > >  void rte_bus_dump(FILE *f);
> > > >  /**
> > > >+ * Bus match function.
> > > >+ *
> > > >+ * @param bus
> > > >+ *	bus under test.
> > > >+ *
> > > >+ * @param data
> > > >+ *	data matched
> > > >+ *
> > > >+ * @return
> > > >+ *	0 if the bus does not match.
> > > >+ *	!0 if the bus matches.
> > >
> > > One of the common match function implementation could be simply to match
> > > a string. strcmp itself returns '0' for a successful match.
> > > On the same lines, should this function return value be reversed?
> > > -
> > > 0 if match
> > > !0 if not a match
> > > -
> > > That way, people would not have to change either the way strcmp works,
> > > for example, or the way various APIs expect '0' as success.
> > >
> > > same for rte_device_match_t as well. (in next patch)
> > >
> > 
> > It was actually a point I hesitated a little before submitting this
> > version.
> > 
> > The logic behind strcmp is that you can express three states: greater
> > than, equal, lower than, thus having total order within the string set.
> > 
> > Here, buses are not ordered (logically). Having a bus lower or greater
> > than some arbitrary data does not mean much.
> 
> I agree about the match() fn - but, this is not what I meant. 
> My point was that ideally for implementation of callbacks, applications
> would more often use the strcmp function (matching name of the bus) than
> the match() callback.
> 
> Further, this semantic is being followed by other DPDK APIs as well - so,
> my intent was to make this also inline with those.
> 

Ah, I see your point now. It makes sense.
The API is now the same.

> > 
> > Anyway, this was my reasoning for following Jan's proposal on this, but
> > I'm not against changing this API. Maybe having to possibility to
> > express total order could be useful eventually. I don't have a strong
> > opinion on this so unless someone shouts about it, I will follow your
> > remark.
> 
> Thank you!
> 
> > 
> <...snip...>

-- 
Gaëtan Rivet
6WIND