[dpdk-dev] [PATCH v2 01/11] bus: add bus iterator to find a particular bus
Gaëtan Rivet
gaetan.rivet at 6wind.com
Thu Jun 8 10:05:14 CEST 2017
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 at 6wind.com]
> > Sent: Wednesday, June 07, 2017 6:58 PM
> > To: Shreyansh Jain <shreyansh.jain at nxp.com>
> > Cc: dev at dpdk.org; Jan Blunck <jblunck at 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 at infradead.org>
> > > >
> > > >Signed-off-by: Jan Blunck <jblunck at infradead.org>
> > > >Signed-off-by: Gaetan Rivet <gaetan.rivet at 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
More information about the dev
mailing list