From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id DAA0A11D9 for ; Tue, 31 Jan 2017 15:52:53 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP; 31 Jan 2017 06:52:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,315,1477983600"; d="scan'208";a="37790256" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 31 Jan 2017 06:52:52 -0800 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 31 Jan 2017 06:52:52 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.230]) by fmsmsx111.amr.corp.intel.com ([169.254.12.234]) with mapi id 14.03.0248.002; Tue, 31 Jan 2017 06:52:52 -0800 From: "Wiles, Keith" To: Pascal Mazon CC: "dev@dpdk.org" Thread-Topic: [PATCH 1/6] net/tap: use correct tap name Thread-Index: AQHSe6ayvsixiw0FGEaIJx56SFpb9qFTMjEA Date: Tue, 31 Jan 2017 14:52:51 +0000 Message-ID: <8DBD7660-7D81-4910-831B-00D7CB41FF39@intel.com> References: <1485855778-15496-1-git-send-email-pascal.mazon@6wind.com> In-Reply-To: <1485855778-15496-1-git-send-email-pascal.mazon@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.141.150] Content-Type: text/plain; charset="us-ascii" Content-ID: <53D779C743513542851102F0A785D181@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 14:52:54 -0000 > On Jan 31, 2017, at 3:42 AM, Pascal Mazon wrote: >=20 > dev->data->name contains "net_tap", the device driver name. > dev->data->dev_private->name contains the actual iface name, > e.g. "dtap0". >=20 > 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. >=20 > In any case, it must to be consistent with the tun_alloc() call in > eth_dev_tap_create(). >=20 > Signed-off-by: Pascal Mazon > --- > drivers/net/tap/rte_eth_tap.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) >=20 > 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 =3D dev->data->dev_private; > struct rx_queue *rx =3D &internals->rxq[qid]; > struct tx_queue *tx =3D &internals->txq[qid]; > int fd; > @@ -419,11 +420,10 @@ tap_setup_queue(struct rte_eth_dev *dev, > fd =3D tx->fd; > if (fd < 0) { > RTE_LOG(INFO, PMD, "Add queue to TAP %s for qid %d\n", > - dev->data->name, qid); > - fd =3D tun_alloc(dev->data->name); > + pmd->name, qid); > + fd =3D 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, >=20 > internals->fds[rx_queue_id] =3D 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); >=20 > return 0; > } > @@ -516,7 +516,7 @@ tap_tx_queue_setup(struct rte_eth_dev *dev, > return -1; >=20 > 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); >=20 > return 0; > } > --=20 > 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 sugg= ested 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? >=20 Regards, Keith