From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 5F2BF2C66 for ; Mon, 20 Feb 2017 09:46:13 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2017 00:46:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,185,1484035200"; d="scan'208";a="60381872" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga004.jf.intel.com with ESMTP; 20 Feb 2017 00:46:09 -0800 Date: Mon, 20 Feb 2017 16:48:25 +0800 From: Yuanhan Liu To: Aaron Conole Cc: Thomas Monjalon , Christian Ehrhardt , dev@dpdk.org, David Marchand , Tetsuya Mukawa , Ilya Maximets , Pavel Fedin Message-ID: <20170220084825.GC18844@yliu-dev.sh.intel.com> References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160427230814.GC25677@yliu-dev.sh.intel.com> <3483279.astLCRKhWa@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC] eal: provide option to set vhost_user socket owner/permissions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 08:46:13 -0000 On Wed, Feb 15, 2017 at 09:32:27AM -0500, Aaron Conole wrote: > Thomas Monjalon writes: > > > Was there any progress on this topic? > > Can we close the request? > > http://dpdk.org/patch/12222/ > > No update in almost a year is probably a bad sign. > > >From the OVS side, we've dropped our patches due to too many corner > cases handling this - instead we're opting to use vhost-user client > mode, and punt the issue to the 'other' side. Additionally, I do agree > with the criticism that providing this via an EAL command line option is > wrong. So, I think it can be safely dropped. Yes and I think we already came an agreement on that before. The reason I still kept in patchwork is to let it be a (soft) reminder: it's something might could be enhanced. > That said, if this is something that folks really want to solve, I think > the sanest way is to allow the application to pass in a > file-descriptor. The way unix domain sockets permissions work changes > based on far too many factors to ever provide an API that makes sense, > unless we also bake in tests for various OSes (and possibly even flavors > of OSes). > > Instead, I think DPDK should allow the application to open the unix > domain socket in whatever manner it chooses, doing whatever tricks are > required to set permissions or other flags the way it wants, and then > pass the file descriptor into the framework. This would allow doing > sane things like fork()ing, changing current owner and umask, opening > the socket, and passing the descriptor back through a pipe (which works > on FreeBSD and Linux to set the permissions). It allows the application > to be concerned with the file-system details, and lets DPDK merely worry > about the important thing: passing packet data. I think I could consider that if that's really needed, say, a real need from some customers. My last reply to that is, you could use the vhost-user as client mode, whereas the socket file is managed/created by QEMU, thus permission won't be an issue any more. Another thing worth noting is that, IIUC, OVS guys at Ireland were proposing to drop the vhost-user support and replace it with vhost-pmd, whereas you could specific vdev options to specify the socket permissions (and etc) for the server mode. It won't use EAL command line options any more, thus, no block issue. --yliu > > > 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