From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id AF9FC282 for ; Wed, 15 Feb 2017 09:55:47 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id v186so36333256wmd.0 for ; Wed, 15 Feb 2017 00:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=6Ng9MfFsezGIJTttmnOKDEThcMkfEZMggrPohHDbNdY=; b=OzGr7CDu2dIo5ZwG68sU7TY13MPaRX/58XdR+wB+HO3C9cNAw3TSM8+dIrROiDrgXR 9u66DNT+UIlyKKMJCG1z1v6PwZpO8PvabDATP5WVFgLzI9VI/bREH5m6WWC9QMuA/DK2 lESa9LS5M7ai4uNcJdes86OE+JgATcJmjMT/rAHXUzqYsz4mdu2NWXBm6qf10B7Zf4zj 00kthr+yMB2TLCON2b9R0BuHZ/CZEhJVik0lrefXOUQbh5RUP/D0uaLJmnf63DP8WmlF jI+O+btWD1adaYMN2TnPHHkm5TWJP3EE8UA6IWAy1E02DsQCpf8DimPfFYucaqBbsRQr tRPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=6Ng9MfFsezGIJTttmnOKDEThcMkfEZMggrPohHDbNdY=; b=LaSphAAYoyW/PP0CLWz4i6C2tmfZLdJnaFcL5B3uu5gtv/bBheQXfr+EEcS8E3fasY uXDgfSlMLD+gY5zbXyWkoptic9hOWBhzbr/oEAJVw/hBiVQs4fe+ZagpaCKNwOoxCcG9 sTj5O33scpn4TFlM5Uaf1wku9mKhgQvxFnroGx9jrK0YJXMNoHFZtBzNrHYOi1rXPbFM IzhX2MBBjV1o13b7GvkAN5HmPhQcO1hKcErCkdToP5knUnvwO/gihV00zKzDMJsZN3XJ l+DWHMbA66QjwaCXiK3cohqHg+Wse8QVcHMHdpoL+4ofL5JW1JZ6Cv2sFe1BF2nNSdCe EEPA== X-Gm-Message-State: AMke39mWaPnJVa9A7R9SHdyX9+AyqZ4joeETzW+ajZHvJR6awumdl/6Z2ZFZEa79cPQP8kc5 X-Received: by 10.28.126.11 with SMTP id z11mr7069416wmc.13.1487148947151; Wed, 15 Feb 2017 00:55:47 -0800 (PST) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id u198sm6645470wmf.9.2017.02.15.00.55.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 00:55:46 -0800 (PST) From: Thomas Monjalon To: Yuanhan Liu , Christian Ehrhardt Cc: Aaron Conole , dev@dpdk.org, David Marchand , Tetsuya Mukawa , Ilya Maximets , Pavel Fedin Date: Wed, 15 Feb 2017 09:55:45 +0100 Message-ID: <3483279.astLCRKhWa@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160427230814.GC25677@yliu-dev.sh.intel.com> References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160427230814.GC25677@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 08:55:47 -0000 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