From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [PATCH 20/22] net/tap: enable port detach on secondary process Date: Thu, 7 Jun 2018 19:01:09 +0000 Message-ID: <66AC0AE4-15C7-4DEF-B971-714C3C80CCE8@intel.com> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180607123849.14439-21-qi.z.zhang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Thomas Monjalon , "Burakov, Anatoly" , "Ananyev, Konstantin" , "dev@dpdk.org" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" To: "Zhang, Qi Z" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BB1E77EB0 for ; Thu, 7 Jun 2018 21:01:11 +0200 (CEST) In-Reply-To: <20180607123849.14439-21-qi.z.zhang@intel.com> Content-Language: en-US Content-ID: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Jun 7, 2018, at 5:38 AM, Qi Zhang wrote: >=20 > Previously, detach port on secondary process will mess primary > process and cause same device can't be attached again, by take > advantage of rte_eth_release_port_local, we can support this with > minor change. Previously, detach ports on secondary process will mess with the primary process and cause the device to be not able to attach again. Taking advantage of the rte_eth_release_port_local call we can fix the problem with minor changes. >=20 > Signed-off-by: Qi Zhang > --- > drivers/net/tap/rte_eth_tap.c | 17 +++++++++++++++-- > 1 file changed, 15 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.= c > index 5531fe9d9..56d3b6cc9 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -1759,6 +1759,7 @@ rte_pmd_tap_probe(struct rte_vdev_device *dev) > } > /* TODO: request info from primary to set up Rx and Tx */ > eth_dev->dev_ops =3D &ops; > + eth_dev->device =3D &dev->device; > rte_eth_dev_probing_finish(eth_dev); > return 0; > } > @@ -1827,12 +1828,24 @@ rte_pmd_tap_remove(struct rte_vdev_device *dev) > { > struct rte_eth_dev *eth_dev =3D NULL; > struct pmd_internals *internals; > + const char *name; > int i; >=20 > + name =3D rte_vdev_device_name(dev); > /* find the ethdev entry */ > - eth_dev =3D rte_eth_dev_allocated(rte_vdev_device_name(dev)); > + eth_dev =3D rte_eth_dev_allocated(name); > if (!eth_dev) > - return 0; > + return -ENODEV; > + > + if (rte_eal_process_type() !=3D RTE_PROC_PRIMARY) { > + /* detach device on local pprocess only */ /pprocess/process/ > + if (strlen(rte_vdev_device_args(dev)) =3D=3D 0) What does strlen() do with a null string returned by rte_vdev_device_args()= , I believe it just returns with zero, but we need to make sure. If it does= not then we must protect strlen(). > + return rte_eth_dev_release_port_local(eth_dev); > + /** > + * else this is a private device for current process > + * so continue with normal detach scenario > + */ > + } >=20 > internals =3D eth_dev->data->dev_private; >=20 > --=20 > 2.13.6 >=20 Regards, Keith