From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 184705593 for ; Fri, 29 Apr 2016 17:52:29 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id a17so43412025wme.0 for ; Fri, 29 Apr 2016 08:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:organization:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=lEoo1IQJnyKGbBTYagG1zzmibh5lTKzk45hhWDtrUYk=; b=vZlr0mxHayPXBH1wOaBjyB8Yt+axnGn9bykU3FbrT0y6W5uvTEIXjBt742G6G0iI6+ Vx2KkYy78YX2pxO/AEM35dZV94bxfsQ8ywrEy6uxpz/kqu2ORQSf8CRMLf2W9fQJaDjr XiGqkYoRUXFAxhG/aY7V8HfIN2ijW0zmnkJ2tibprk8ZxaGTIfQ2PdHiJIwpe/DGxIXq V3tWDQbKCa+ee4Miqc4IgdexJAT9gEkrhW4P1m0dyu8TF6J9Zu2O2Ib0dE6QRLlMAKcs wsV9tR7vUp1H7mnneJHRlcMhkp+VlDKggVP6WopbVaqz0amGrCIn9CfSjxrON7y05Tf1 fhnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=lEoo1IQJnyKGbBTYagG1zzmibh5lTKzk45hhWDtrUYk=; b=PjWfpbjoy6dBcvVUVeq83jycQ+uxqUd7YghHjSUGecjWJvJnIZFEmPmO6OEQE7j+FO 1QCpsVrReriRcX/StDkk4PcZZqii6IST4WflDhuix+lec95ZplY0zjwenDg5QbBc/Suj 5YxOuRjdxszL8PWtVo7jwpI3lSXxbaKTGURh5Ig2XwNX+DYsvjIdx2RqlJmqIShNpImI mFphZgOn0S6INxVD7E1ikeJRphwpD5Ac6qaP41Ah/wPBV+gPYlXDtiS3ooytpJSPTqOF kuC6lSHqUgLpKxriZJlzuhgu7DBmkB2F4cjgYM5/yjAJZC/A7Q1XZQw1rrckrzoEUWRO 55wA== X-Gm-Message-State: AOPr4FVZCQjiGIe8koDp4lGemc5H9A/9FvziWH0gNTiKOJG2cPNO1RszvBE7QCR8DdNjkHDj X-Received: by 10.28.52.75 with SMTP id b72mr4949932wma.98.1461945148916; Fri, 29 Apr 2016 08:52:28 -0700 (PDT) Received: from xps13.localnet (51.111.75.86.rev.sfr.net. [86.75.111.51]) by smtp.gmail.com with ESMTPSA id iv1sm15390816wjb.34.2016.04.29.08.52.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 08:52:27 -0700 (PDT) From: Thomas Monjalon To: dev@dpdk.org, David Verbeiren Date: Fri, 29 Apr 2016 17:52:26 +0200 Message-ID: <487342714.Ci5BV3hPHa@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1456310006-30296-1-git-send-email-david.verbeiren@gmail.com> References: <1456310006-30296-1-git-send-email-david.verbeiren@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH] ivshmem ring aliases 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: Fri, 29 Apr 2016 15:52:29 -0000 2016-02-24 11:33, David Verbeiren: > The goal of this parch is to allow VMs to use standard ring names regardless of the names > given to the rings by host environment. It applies to configurations using ivshmem. > > With shared memory rings, all VMs share a single namespace for the rings. However, a VM > will typically expect to find its rings with a pre-determined name (e.g. p1_rx, p1_tx) > regardless of how it's deployed, inserted in a service chain, or of which other VMs are > deployed alongside it. Hence, it is desirable to introduce a level of indirection where > the host can set a mapping from the actual ring names (e.g. dpdkr0_rx|tx with OVS) and > the names that will be visible in the VM. This patch provides a simple implementation > of such a mapping scheme. > > Since the mapping must be VM specific, the aliases are inserted into the IVSHMEM metadata > area by the host and the guest side uses thoses aliases when doing rte_ring_lookup(). > > A new function, rte_ivshmem_add_ring_alias() is provided in librte_ivshmem to populate > alias entries in the host environment when creating the per-VM metadata. I'm still not sure this library is a good idea at all. This patch continue the tradition of librte_ivshmem by adding more #ifdef in the code (in rte_ring here). We could also comment the compile time values or the checkpatch warnings. But more importantly, what is the use case of this library and why is it important to have such support in DPDK? > --- a/lib/librte_ring/rte_ring.c > +++ b/lib/librte_ring/rte_ring.c > @@ -352,6 +352,12 @@ rte_ring_lookup(const char *name) > struct rte_ring *r = NULL; > struct rte_ring_list *ring_list; > > +#ifdef RTE_LIBRTE_IVSHMEM > + const char * target_name = rte_eal_ivshmem_alias_get(name); > + if (target_name) > + name = target_name; > +#endif This #ifdef should not exist.