From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 7FB1C1BB2C for ; Fri, 11 Jan 2019 20:43:12 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2019 11:43:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,466,1539673200"; d="scan'208";a="266455276" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga004.jf.intel.com with ESMTP; 11 Jan 2019 11:43:10 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 11 Jan 2019 11:43:09 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.160]) by FMSMSX114.amr.corp.intel.com ([169.254.6.247]) with mapi id 14.03.0415.000; Fri, 11 Jan 2019 11:43:09 -0800 From: "Wiles, Keith" To: Stephen Hemminger CC: "dev@dpdk.org" , "hfli@netitest.com" Thread-Topic: [dpdk-dev] [PATCH 5/6] net/tap: let kernel choose tun device name Thread-Index: AQHUqdiZ5Lz555fLPEKvc3iIs09cm6Wq/iwA Date: Fri, 11 Jan 2019 19:43:09 +0000 Message-ID: <34BDCAAA-A72E-4B9A-8C43-860CEC756588@intel.com> References: <20190111180659.5972-1-stephen@networkplumber.org> <20190111180659.5972-6-stephen@networkplumber.org> In-Reply-To: <20190111180659.5972-6-stephen@networkplumber.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.35.122] Content-Type: text/plain; charset="us-ascii" Content-ID: <9346D3CFDCF4AB42975BA7D3CA132255@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 5/6] net/tap: let kernel choose tun device 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: Fri, 11 Jan 2019 19:43:13 -0000 > On Jan 11, 2019, at 12:06 PM, Stephen Hemminger wrote: >=20 > Assigning tun and tap index in DPDK tap device driver is racy and > fails if used with primary/secondary process model. Instead, use the > kernel feature of device wildcarding where if a name with %d is used > the kernel will fill in the next available device. >=20 > Reported-by: hfli@netitest.com > Fixes: 02f96a0a82d1 ("net/tap: add TUN/TAP device PMD") > Signed-off-by: Stephen Hemminger > --- > drivers/net/tap/rte_eth_tap.c | 32 ++++++++++++++++---------------- > 1 file changed, 16 insertions(+), 16 deletions(-) >=20 > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.= c > index 50d6729cb609..b836c1ae3d4e 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -79,9 +79,6 @@ static const char *valid_arguments[] =3D { > NULL > }; >=20 > -static unsigned int tap_unit; > -static unsigned int tun_unit; > - > static char tuntap_name[8]; >=20 > static volatile uint32_t tap_trigger; /* Rx trigger */ > @@ -151,8 +148,6 @@ tun_alloc(struct pmd_internals *pmd, int is_keepalive= ) > IFF_TAP : IFF_TUN | IFF_POINTOPOINT; > strlcpy(ifr.ifr_name, pmd->name, IFNAMSIZ); >=20 > - TAP_LOG(DEBUG, "ifr_name '%s'", ifr.ifr_name); > - > fd =3D open(TUN_TAP_DEV_PATH, O_RDWR); > if (fd < 0) { > TAP_LOG(ERR, "Unable to create %s interface", tuntap_name); > @@ -186,6 +181,13 @@ tun_alloc(struct pmd_internals *pmd, int is_keepaliv= e) > goto error; > } >=20 > + /* > + * Name passed to kernel might be wildcard like dtun%d > + * and need to find the resulting device. > + */ > + TAP_LOG(DEBUG, "Device name is '%s'", ifr.ifr_name); > + strlcpy(pmd->name, ifr.ifr_name, RTE_ETH_NAME_MAX_LEN); > + > if (is_keepalive) { > /* > * Detach the TUN/TAP keep-alive queue > @@ -1756,6 +1758,7 @@ eth_dev_tap_create(struct rte_vdev_device *vdev, ch= ar *tap_name, > TAP_LOG(ERR, "Unable to create %s interface", tuntap_name); > goto error_exit; > } > + TAP_LOG(INFO, "allocated %s", pmd->name); Is this one required to be INFO as you wanted to reduce log clutter? I am o= k with it, but thought I would ask. >=20 > ifr.ifr_mtu =3D dev->data->mtu; > if (tap_ioctl(pmd, SIOCSIFMTU, &ifr, 1, LOCAL_AND_REMOTE) < 0) > @@ -1917,8 +1920,8 @@ set_interface_name(const char *key __rte_unused, > } > strlcpy(name, value, RTE_ETH_NAME_MAX_LEN); > } else { > - snprintf(name, RTE_ETH_NAME_MAX_LEN, "%s%d", > - DEFAULT_TAP_NAME, tun_unit - 1); > + snprintf(name, RTE_ETH_NAME_MAX_LEN, "%s%%d", > + DEFAULT_TAP_NAME); I guess a short comment would be nice for the reader to know that this is a= kernel feature syntax. > } > return 0; > } > @@ -2031,8 +2034,8 @@ rte_pmd_tun_probe(struct rte_vdev_device *dev) > return 0; > } >=20 > - snprintf(tun_name, sizeof(tun_name), "%s%u", > - DEFAULT_TUN_NAME, tun_unit++); > + snprintf(tun_name, sizeof(tun_name), "%s%%d", > + DEFAULT_TUN_NAME); Same here. >=20 > if (params && (params[0] !=3D '\0')) { > TAP_LOG(DEBUG, "parameters (%s)", params); > @@ -2052,17 +2055,15 @@ rte_pmd_tun_probe(struct rte_vdev_device *dev) > } > pmd_link.link_speed =3D ETH_SPEED_NUM_10G; >=20 > - TAP_LOG(DEBUG, "Initializing pmd_tun for %s as %s", > - name, tun_name); > + TAP_LOG(DEBUG, "Initializing pmd_tun for %s", name); >=20 > ret =3D eth_dev_tap_create(dev, tun_name, remote_iface, 0, > - ETH_TUNTAP_TYPE_TUN); > + ETH_TUNTAP_TYPE_TUN); >=20 > leave: > if (ret =3D=3D -1) { > TAP_LOG(ERR, "Failed to create pmd for %s as %s", > name, tun_name); > - tun_unit--; /* Restore the unit number */ > } > rte_kvargs_free(kvlist); >=20 > @@ -2218,8 +2219,8 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev) > } >=20 > speed =3D ETH_SPEED_NUM_10G; > - snprintf(tap_name, sizeof(tap_name), "%s%u", > - DEFAULT_TAP_NAME, tap_unit++); > + snprintf(tap_name, sizeof(tap_name), > + "%s%%d", DEFAULT_TAP_NAME); > memset(remote_iface, 0, RTE_ETH_NAME_MAX_LEN); >=20 > if (params && (params[0] !=3D '\0')) { > @@ -2282,7 +2283,6 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev) > rte_mp_action_unregister(TAP_MP_KEY); > tap_devices_count--; > } > - tap_unit--; /* Restore the unit number */ > } > rte_kvargs_free(kvlist); >=20 > --=20 > 2.20.1 >=20 Regards, Keith