From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 74227E6D for ; Thu, 28 Apr 2016 01:05:46 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 27 Apr 2016 16:05:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,544,1455004800"; d="scan'208";a="964191724" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 27 Apr 2016 16:05:41 -0700 Date: Wed, 27 Apr 2016 16:08:14 -0700 From: Yuanhan Liu To: Aaron Conole Cc: Thomas Monjalon , Christian Ehrhardt , dev@dpdk.org, "Xie, Huawei" , David Marchand , Panu Matilainen , Tetsuya Mukawa , Ilya Maximets , Pavel Fedin Message-ID: <20160427230814.GC25677@yliu-dev.sh.intel.com> References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160426041637.GE7832@yliu-dev.sh.intel.com> <1821126.OuT4M3UuqJ@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: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 23:05:47 -0000 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