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 BA7052BBD for ; Tue, 26 Apr 2016 15:33:50 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 2BFF778224; Tue, 26 Apr 2016 13:33:50 +0000 (UTC) Received: from aconole-fed23 (dhcp-25-211.bos.redhat.com [10.18.25.211]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3QDXm36001779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Apr 2016 09:33:49 -0400 From: Aaron Conole To: Thomas Monjalon Cc: Yuanhan Liu , Christian Ehrhardt , dev@dpdk.org, "Xie\, Huawei" , David Marchand , Panu Matilainen References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160426041637.GE7832@yliu-dev.sh.intel.com> <1821126.OuT4M3UuqJ@xps13> Date: Tue, 26 Apr 2016 09:33:48 -0400 In-Reply-To: <1821126.OuT4M3UuqJ@xps13> (Thomas Monjalon's message of "Tue, 26 Apr 2016 10:52:32 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 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: Tue, 26 Apr 2016 13:33:51 -0000 Thomas Monjalon writes: > 2016-04-25 21:16, Yuanhan Liu: >> On Mon, Apr 25, 2016 at 11:18:16AM +0200, Christian Ehrhardt wrote: >> > The API doesn't hold a way to specify a owner/permission set for vhost_user >> > created sockets. >> >> Yes, it's kind of like a known issue. So, thanks for bringing it, with >> a solution, for dicussion (cc'ed more people). > [...] >> > But I'd be interested if DPDK in general would be interested in: >> > a) an approach like this? >> >> You were trying to add a vhost specific stuff as EAL command option, >> which is something we might should try to avoid. > > Yes, -1 > >> > 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? > And for vhost PMD? What about devargs parameters? 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? >> > 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. 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