From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) by dpdk.org (Postfix) with ESMTP id 739FA2E7B for ; Tue, 26 Apr 2016 09:25:05 +0200 (CEST) Received: by mail-qg0-f50.google.com with SMTP id f74so2072886qge.2 for ; Tue, 26 Apr 2016 00:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UjVVmColPN22HRMAAnKgJgUr+kZFWamHENQwSTYmVx8=; b=K1aXpGP4cH5+JAxYaHILBbDYXRsn8UNsiZarxI8OmKiFn5MnkI+ulcw0Qhc50yVonB kvGoxPYr6NcOGRBkcjWde1/oRlUEiOmmjlTXb/ZMynfjLYMjmr+d364Hw72/gtzaUx9u ar5lML6R03JIP9NgidUcXaRsdfbn+7sxpamy0QJ19pKl6X79AE13QOtvrYTeCUFlwdcG 8QYDa9ou0LEDCPS+nj2dCLL7MDYleYyBrSR2Z+6fBeemn7G17UQ7Uur0t6SJIzy0yopm 9Rz+crWO32GlbZhnvVJP0Bd49tn6I9mHP1ZKqUmyciloEVgpi2VuofUQoDxmuEKojl/W M8Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UjVVmColPN22HRMAAnKgJgUr+kZFWamHENQwSTYmVx8=; b=CGYyzBxGpJ63LpMQ9OuxV+Zb5r4/7yXNhmTK/bNTN5/GFWYqhOuD2mRtDSqmlTtaDC 9BcUsNm+0Z/we6T2/KvdfMefdMx/hdB+/43wL4E3R3Lf8Oi5UPMNVUEweorTECVVKOf6 GBsTZKrjOl2aRxWYuSBqoYfiRNaggYh2zx6kmuSZwdpUrKFaPZT7dAd04QQX7R5t7Nbs ChtGlcQqWbQ7sV7gx2s/GLeqLVn6jZLGe53DjLtkjlL0bZZHcktXwMM8S5zSIp8gwU4B Ov+7qQ41altWYG5wxiHBWtp/HKxFCGk59YxQhmPkNIUBT6cFTWEPl8Swbp0JvWFqLZa8 5t5Q== X-Gm-Message-State: AOPr4FUkGBkRcWPhvv+KXq24J4WV1Egq/x1IK5r23iSLwNPrOInlCnjIxByOcBf7ROUtTBML0AdHaRGk6iNWCuu/ X-Received: by 10.140.196.74 with SMTP id r71mr785156qha.41.1461655504782; Tue, 26 Apr 2016 00:25:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.212.91 with HTTP; Tue, 26 Apr 2016 00:24:45 -0700 (PDT) In-Reply-To: <20160426041637.GE7832@yliu-dev.sh.intel.com> References: <1461575896-17409-1-git-send-email-christian.ehrhardt@canonical.com> <20160426041637.GE7832@yliu-dev.sh.intel.com> From: Christian Ehrhardt Date: Tue, 26 Apr 2016 09:24:45 +0200 Message-ID: To: Yuanhan Liu Cc: Aaron Conole , dev , "Xie, Huawei" , Thomas Monjalon , David Marchand , Panu Matilainen Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 07:25:05 -0000 Thanks, great that you added more on CC for a wider discussion - I think that is the only right way to go. Just to "defend" a bit - solution a) was created under the special circumstance that I wanted a workaround that would work today. But that is/was special to what I package with DPDK 2.2 + OVS 2.5 as of today - and therefore was the right place for a fast interim fix for me. I totally agree that the A in EAL was meant for abstraction and we might want to avoid vhost specific things in there that in the long run. I like your suggestion of a new API as a proper long term solution, but I don't feel deeply enough involved yet on the API level to give it any judgement. So I look forward for more opinions on it. P.S. the patch bot hit me hard with 2 pages of space/bracket issues, sorry for that - but it was only meant as RFC after all :-) Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Tue, Apr 26, 2016 at 6:16 AM, Yuanhan Liu wrote: > 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). > > > I don't even think an API change would make that much sense. > > > > Projects consuming DPDK start to do 'their own workarounds' like > openvswitch > > https://patchwork.ozlabs.org/patch/559043/ > > https://patchwork.ozlabs.org/patch/559045/ > > But for this specific example they are blocked/stalled behind a bigger > > rework (https://patchwork.ozlabs.org/patch/604898/). > > Also one could ask why each project would need their own workaround. > > > > At the same time - as I want it for existing code linking against DPDK I > > wanted to avoid changing API/ABI. That way I want to provide something > existing > > users could utilize. So I created a DPDK EAL commandline option based > ideas in > > the former patches. > > > > For myself I consider this a nice interim solution for existing released > > Openvswitch+DPDK solution. And I intend to put it as delta into the DPDK > 2.2 > > currently packaged in Ubuntu to get it working more smoothly with > > openvswitch 2.5. > > > > 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. > > > 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. > > > 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. > > And I'd like to hear what others would say. > > Thanks. > > --yliu >