From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 1B1499E7 for ; Wed, 15 Feb 2017 15:32:30 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 224CA80465; Wed, 15 Feb 2017 14:32:30 +0000 (UTC) Received: from dhcp-25-97.bos.redhat.com (dhcp-25-172.bos.redhat.com [10.18.25.172]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1FEWS3J013157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Feb 2017 09:32:29 -0500 From: Aaron Conole To: Thomas Monjalon Cc: Yuanhan Liu , Christian Ehrhardt , dev@dpdk.org, David Marchand , Tetsuya Mukawa , Ilya Maximets , Pavel Fedin References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160427230814.GC25677@yliu-dev.sh.intel.com> <3483279.astLCRKhWa@xps13> Date: Wed, 15 Feb 2017 09:32:27 -0500 In-Reply-To: <3483279.astLCRKhWa@xps13> (Thomas Monjalon's message of "Wed, 15 Feb 2017 09:55:45 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 15 Feb 2017 14:32:30 +0000 (UTC) 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: Wed, 15 Feb 2017 14:32:30 -0000 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. 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. > 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