DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>
Cc: Aaron Conole <aconole@redhat.com>,
	dev@dpdk.org, David Marchand <david.marchand@6wind.com>,
	Tetsuya Mukawa <mukawa@igel.co.jp>,
	Ilya Maximets <i.maximets@samsung.com>,
	Pavel Fedin <p.fedin@samsung.com>
Subject: Re: [dpdk-dev] [RFC] eal: provide option to set vhost_user socket owner/permissions
Date: Wed, 15 Feb 2017 09:55:45 +0100	[thread overview]
Message-ID: <3483279.astLCRKhWa@xps13> (raw)
In-Reply-To: <20160427230814.GC25677@yliu-dev.sh.intel.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

  reply	other threads:[~2017-02-15  8:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25  9:18 Christian Ehrhardt
2016-04-26  4:16 ` Yuanhan Liu
2016-04-26  7:24   ` Christian Ehrhardt
2016-04-26  8:52   ` Thomas Monjalon
2016-04-26 13:33     ` Aaron Conole
2016-04-27 23:08       ` Yuanhan Liu
2017-02-15  8:55         ` Thomas Monjalon [this message]
2017-02-15 14:32           ` Aaron Conole
2017-02-20  8:48             ` 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=3483279.astLCRKhWa@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=aconole@redhat.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=i.maximets@samsung.com \
    --cc=mukawa@igel.co.jp \
    --cc=p.fedin@samsung.com \
    --cc=yuanhan.liu@linux.intel.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).