From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CA0D91023 for ; Tue, 31 Jan 2017 16:14:51 +0100 (CET) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP; 31 Jan 2017 07:14:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,315,1477983600"; d="scan'208";a="54081864" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.38]) ([10.237.220.38]) by orsmga004.jf.intel.com with ESMTP; 31 Jan 2017 07:14:49 -0800 To: "Wiles, Keith" , Pascal Mazon References: <1485855778-15496-1-git-send-email-pascal.mazon@6wind.com> <8DBD7660-7D81-4910-831B-00D7CB41FF39@intel.com> Cc: "dev@dpdk.org" From: Ferruh Yigit Message-ID: <783a3194-ef15-a495-4c57-de27e3d550ba@intel.com> Date: Tue, 31 Jan 2017 15:14:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <8DBD7660-7D81-4910-831B-00D7CB41FF39@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/6] net/tap: use correct tap name 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: Tue, 31 Jan 2017 15:14:52 -0000 On 1/31/2017 2:52 PM, Wiles, Keith wrote: > >> On Jan 31, 2017, at 3:42 AM, Pascal Mazon wrote: >> >> dev->data->name contains "net_tap", the device driver name. >> dev->data->dev_private->name contains the actual iface name, >> e.g. "dtap0". >> >> In tun_alloc() especially, we want to use the latter. Otherwise the >> netdevice would be wrongly named "net_tap". Furthermore, creating >> several tap vdev would point to the same netdevice. >> >> In any case, it must to be consistent with the tun_alloc() call in >> eth_dev_tap_create(). >> >> Signed-off-by: Pascal Mazon >> --- >> drivers/net/tap/rte_eth_tap.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c >> index 91f63f5468b2..8faf08551b9e 100644 >> --- a/drivers/net/tap/rte_eth_tap.c >> +++ b/drivers/net/tap/rte_eth_tap.c >> @@ -410,6 +410,7 @@ tap_setup_queue(struct rte_eth_dev *dev, >> struct pmd_internals *internals, >> uint16_t qid) >> { >> + struct pmd_internals *pmd = dev->data->dev_private; >> struct rx_queue *rx = &internals->rxq[qid]; >> struct tx_queue *tx = &internals->txq[qid]; >> int fd; >> @@ -419,11 +420,10 @@ tap_setup_queue(struct rte_eth_dev *dev, >> fd = tx->fd; >> if (fd < 0) { >> RTE_LOG(INFO, PMD, "Add queue to TAP %s for qid %d\n", >> - dev->data->name, qid); >> - fd = tun_alloc(dev->data->name); >> + pmd->name, qid); >> + fd = tun_alloc(pmd->name); >> if (fd < 0) { >> - RTE_LOG(ERR, PMD, "tun_alloc(%s) failed\n", >> - dev->data->name); >> + RTE_LOG(ERR, PMD, "tun_alloc(%s) failed\n", pmd->name); >> return -1; >> } >> } >> @@ -493,7 +493,7 @@ tap_rx_queue_setup(struct rte_eth_dev *dev, >> >> internals->fds[rx_queue_id] = fd; >> RTE_LOG(INFO, PMD, "RX TAP device name %s, qid %d on fd %d\n", >> - dev->data->name, rx_queue_id, internals->rxq[rx_queue_id].fd); >> + internals->name, rx_queue_id, internals->rxq[rx_queue_id].fd); >> >> return 0; >> } >> @@ -516,7 +516,7 @@ tap_tx_queue_setup(struct rte_eth_dev *dev, >> return -1; >> >> RTE_LOG(INFO, PMD, "TX TAP device name %s, qid %d on fd %d\n", >> - dev->data->name, tx_queue_id, internals->txq[tx_queue_id].fd); >> + internals->name, tx_queue_id, internals->txq[tx_queue_id].fd); >> >> return 0; >> } >> -- >> 2.8.0.rc0 > > I have not looked at the code completely yet, but it seems reasonable. The only problem is I did have a cleanup patch for the TAP PMD, but Ferruh suggested it was way too many changes at this time for RC2. Are we still under that restriction or when would you suggest this be applied? RC2 is out now, I was aiming that tap PMD works with testpmd with RC2. Now there is some time for RC3 and some fixes can go in, no new features but fixes. > >> > > Regards, > Keith >