On Tue, Apr 26, 2016 at 09:33:48AM -0400, Aaron Conole wrote:
> >> > b) would prefer a change of the API?
> >>
> >> Adding a new option to the current register API might will not work well,
> >> either. It gives you no ability to do a dynamic change later. I mean,
> >> taking OVS as an example, OVS provides you the flexible ability to do all
> >> kinds of configuration in a dynamic way, say number of rx queues. If we
> >> do the permissions setup in the register time, there would be no way to
> >> change it later, right?
> >>
> >> So, I'm thinking that we may could add a new API for that? It then would
> >> allow applications to change it at anytime.
> >
> > A vhost API in the library?
Yes, I supposed so.
> > And for vhost PMD?
Technically, vhost PMD is an application (or precisely, an user) of
vhost lib. So, it's supposed to invoke the new API.
> What about devargs parameters?
Yes, and it then invoke the API, as stated above.
>
> I don't know the most sane solution here, other than to echo the
> sentiment that a new API for this is probably appropriate. Where that
> API lives, and how it looks should be hashed out. For now, I'm working
> on a solution in OVS because no such API or facility exists in DPDK.
>
> Actually, there are a number of edge cases with vhost-user sockets. I
> don't want to get into all of them, but since we're discussing the API a
> bit here, I'd like to also bring up the following:
>
> What is the desired behavior w.r.t. file cleanup when the application
> crashes, restarts, and tells DPDK to use that file again (which hasn't
> been cleaned up due to the crash)?
> At present, the vhost-user code errors out. But how does the
> application correct the situation without deleting arbitrary files on
> the filesystem?
Oops, yes, that's another one. We also had some discussion before:
http://dpdk.org/ml/archives/dev/2015-December/030326.html
It ended up with an agreement that we should let the application to
handle it, due to it's a path provided by the application, though
it's DPDK does the creation.
>
> >> > c) consider it an issue of consuming projects and let them take care?
> >>
> >> It's not exactly an issue of consuming projects; we created the socket
> >> file after all.
> >
> > Yes
>
> Just want to reiterate at present there is no solution, so projects will
> invent their own. I can point to Ubuntu and Red Hat customer bugs which
> require silly workarounds like "after you started a bunch of stuff, go
> to the directory and run chmod/chown."
>
> I'm actually not opposed to any solution that seems sane. If DPDK takes
> the stance that the file is specified by the application, and therefore
> "file management" activities (removal, permissions, ownership, etc.) are
> the responsibility of the application, so be it.
Exactly. But DPDK, as a library, could provides some handy APIs to make
the application developer's life be less painful. So, that also echoes
to what we have said before: we provide the tool, you use it, and it's
you to make sure it's right.
--yliu
> If the stance is that
> DPDK owns the management of the file, so be that as well. I think the
> first case is easier for the library maintainers (do nothing), the
> second is easier for the applications (use these semantics).
>
> If it really is the responsibility of DPDK, then I think the only sane
> approach is an API for managing this. That may require an additional
> library framework to link the vhost-user PMD and rte_ethdev facilities
> so that a common API could be provided.
>
> Just my $.02.
>
> Thanks,
> Aaron
