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

[Shreyansh Jain <shreyansh.jain@nxp.com>]

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.

> 
> 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...>