From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id DD38B952 for ; Mon, 6 Mar 2017 15:58:01 +0100 (CET) Received: by mail-wr0-f171.google.com with SMTP id u48so118508014wrc.0 for ; Mon, 06 Mar 2017 06:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=h9XabcX6eMR1TZ+2zMNk/ko76yTBdODYgaGehAnLgkc=; b=o5J/vm5yuanmU0EVibR+5l/MpMYCowQyKzcCkwfJylB/qpHKitLX9B9Ucn3El/Cf2M Gcn7W1cJN0VkYi0BSRlOe/ukPHg+0qQ1iVRM7rmNsRfa+0l2seZrzm4aEILyCGVKMxPo AA8KBgGquA4YGYMprxjRvbUCzJsSZXoFEIFP3TGlp4fyEYP6mqRdUxSkNa7u3vcA1pCg 3GHjlNQV5z0aW9QHCLlQZ5BsSBkm8GVrQeoHTP6NGyuHKeLrdGybt/P3ZoDc4BxBv8Kl crfbKhnezTNfpuD5wRp7IQwZjNExv9bzu4wxwbkxVA9NNvXPXDCMozKDp2DeUp+CkVol Xmtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=h9XabcX6eMR1TZ+2zMNk/ko76yTBdODYgaGehAnLgkc=; b=mueuajLP7nTB1gpLO4lsdWNhwZyE1nG9+sXH6YcrcctqQ4HiID7yH7Q8DLZFR8vz3u 2jlnRW77DjaynXz/SPlQimzLXxjOPGK9Lvvn7UiiI0MXCOM7Cmxu6D+oBQ5TLfxTtita DQw/dD8/oPPT7TaCSKDt6ZkzZuSywW4slcDMjtdz+iRKP9fN6MhCM60mlr6mQCzZuOKa 5dLjm1xoLJvy9dPKib0tmMdvvRnb6UkZ5fGZ/9fMWYl1hec+SHmZ8mpelWE7muVUeilV xP8TOySGuWmHn2j2SytYqozkJrShemEMVgkFxdb4ZVhlkcNxOhCUP8HMZK8dtyjV7tq7 j8xg== X-Gm-Message-State: AMke39mBWlECER5ivN/Dh/yUXmQPJgK+4Omv4vCtOBAnewN9vcm/dpi+u6O7AOtgp4+ebx4s X-Received: by 10.223.130.101 with SMTP id 92mr15334602wrb.192.1488812281555; Mon, 06 Mar 2017 06:58:01 -0800 (PST) Received: from paques.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 11sm27311563wrb.10.2017.03.06.06.58.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 06:58:01 -0800 (PST) Date: Mon, 6 Mar 2017 15:57:50 +0100 From: Pascal Mazon To: Ferruh Yigit Cc: keith.wiles@intel.com, dev@dpdk.org Message-ID: <20170306155750.55dfb49f@paques.dev.6wind.com> In-Reply-To: References: <1ad979ca71ba1ebe10572237a6a5b4694c23b645.1488531158.git.pascal.mazon@6wind.com> <64e79c8c7398e0af093168d614c0ca62dc28377e.1488808159.git.pascal.mazon@6wind.com> Organization: 6WIND X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2] net/tap: fix dev name look-up 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: Mon, 06 Mar 2017 14:58:02 -0000 On Mon, 6 Mar 2017 14:27:18 +0000 Ferruh Yigit wrote: > On 3/6/2017 1:51 PM, Pascal Mazon wrote: > > Store the device name in dev->data->name, to have symmetrical > > behavior between rte_pmd_tap_probe(name) and > > rte_pmd_tap_remove(name). > > > > The netdevice name (linux interface name) is stored in the name > > field of struct pmd_internals. > > +1 for this. > > > > > There's no need to allocate an rte_eth_dev_data, as it is done in > > rte_eth_dev_allocate()/rte_eth_dev_data_alloc(). > > Allocating rte_eth_dev_data, although rte_eth_dev_allocate() does > already, common practice for virtual devices, for a reason. > > rte_eth_dev_allocate() allocates device data from a shared memory, so > that multiple DPDK processes can access same device data, this may > make sense for physical devices, since there is a single physical > resource. > > But for virtual devices, each DPDK process may want to have > independent instance of the virtual device, that is why PMD itself > allocates data and overwrites with existing dev->data. > > Also this may lead unexpected results for some multi process use > cases, like secondary process virtual device corrupt primary process > physical device data. > > I believe it is good to keep this as it is. > I see your point. I'll send a v3 with just the correct "name" used for allocation. And I'll move the snprintf(data->name) closer, to insist it must use the same name as in allocation. Regards, Pascal > > > > Signed-off-by: Pascal Mazon > <...>