Re: [RFC] eal: provide option to set vhost_user socket owner/permissions

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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