From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: Ciara Loftus <ciara.loftus@intel.com>,
dev@dpdk.org, "Wiles, Keith" <keith.wiles@intel.com>
Subject: Re: [dpdk-dev] [PATCH] net/vhost: Add function to retreive the 'vid' for a given port id
Date: Fri, 23 Sep 2016 12:26:41 +0800 [thread overview]
Message-ID: <20160923042641.GP23158@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <3895093.sl81aq1Okb@xps13>
On Thu, Sep 22, 2016 at 06:43:55PM +0200, Thomas Monjalon wrote:
> > > > > > > There could be a similar need in other PMD.
> > > > > > > If we can get an opaque identifier of the device which is not the port id,
> > > > > > > we could call some specific functions of the driver not implemented in
> > > > > > > the generic ethdev API.
> > > > > >
> > > > > > That means you have to add/export the PMD API first. Isn't it against what
> > > > > > you are proposing -- "I think we should not add any API to the PMDs" ;)
> > > > >
> > > > > Yes you are totally right :)
> > > > > Except that in vhost case, we would not have any API in the PMD.
> > > > > But it would allow to have some specific API in other PMDs for the features
> > > > > which do not fit in a generic API.
> > > >
> > > > So, does that mean you are okay with this patch now? I mean, okay to introduce
> > > > a vhost PMD API?
> > >
> > > It means I would be in favor of introducing API in drivers for very specific
> > > features.
> > > In this case, I am not sure that retrieving an internal id is very specific.
> >
> > It's not, instead, it's very generic. The "internal id" is actually the
> > public interface to vhost-user application, like "fd" to file APIs.
> >
> > Instead of introducing a few specific wrappers/APIs, I'd prefer to
> > introduce a generic one to get the handle, and let the application to
> > call other vhost APIs.
>
> Yes it makes sense.
> I was thinking of introducing a function to get an internal id from ethdev,
> in order to use it with any driver or underlying library.
> But it would be an opaque pointer and you need an int.
> Note that we can cast an int into a pointer, so I am not sure what is best.
Yes, that should work. But I just doubt what the "opaque pointer" could be
for other PMD drivers, and what the application could do with it. For a
typical nic PMD driver, I can think of nothing is valuable to export to
user applications.
But maybe it's valuable to other virtual PMD drives as well, like the TAP
pmd from Keith?
If so, we may go that way.
Another thought is that, it may be a bit weird to me to introduce an API
to get an opaque pointer. I mean, it's a bit hard to document it, because
it has different meaning for different drivers. Should we list all of
them then?
--yliu
next prev parent reply other threads:[~2016-09-23 4:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-13 13:47 Ciara Loftus
2016-09-13 15:10 ` Thomas Monjalon
2016-09-14 4:43 ` Yuanhan Liu
2016-09-14 7:10 ` Thomas Monjalon
2016-09-14 7:21 ` Yuanhan Liu
2016-09-14 8:35 ` Thomas Monjalon
2016-09-18 8:27 ` Yuanhan Liu
2016-09-21 13:07 ` Thomas Monjalon
2016-09-22 2:36 ` Yuanhan Liu
2016-09-22 16:43 ` Thomas Monjalon
2016-09-23 4:26 ` Yuanhan Liu [this message]
2016-09-23 8:43 ` Thomas Monjalon
2016-09-23 9:16 ` Yuanhan Liu
2016-09-23 9:26 ` Loftus, Ciara
2016-09-23 21:23 ` Wiles, Keith
2016-09-26 3:19 ` Yuanhan Liu
2016-09-26 13:12 ` Thomas Monjalon
2016-09-26 13:18 ` Bruce Richardson
2016-09-26 14:26 ` Thomas Monjalon
2016-09-26 14:34 ` Bruce Richardson
2016-09-26 16:24 ` Iremonger, Bernard
2016-09-26 16:55 ` Thomas Monjalon
2016-09-26 17:05 ` Wiles, Keith
2016-09-28 16:59 ` Mcnamara, John
2016-09-29 9:21 ` Mcnamara, John
2016-09-29 9:30 ` Thomas Monjalon
2016-09-29 12:08 ` Yuanhan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160923042641.GP23158@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).