Was there any progress on this topic?
Can we close the request?
http://dpdk.org/patch/12222/
2016-04-27 16:08, Yuanhan Liu:
> 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
