From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6E2DA054F for ; Mon, 15 Feb 2021 17:24:08 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9858A160684; Mon, 15 Feb 2021 17:24:08 +0100 (CET) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by mails.dpdk.org (Postfix) with ESMTP id E41AC160684 for ; Mon, 15 Feb 2021 17:24:06 +0100 (CET) Received: from mail-qv1-f72.google.com ([209.85.219.72]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lBgfO-0007hl-Hx for stable@dpdk.org; Mon, 15 Feb 2021 16:24:06 +0000 Received: by mail-qv1-f72.google.com with SMTP id n1so5491605qvi.4 for ; Mon, 15 Feb 2021 08:24:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hoz8IGl7V6g9BsZlQcU2sVKnXVmkyBqAN7ocoluFru0=; b=r8uDY1TMpiofIAAdpzzgylNfFJPQBO76jFsj+fRSMsNfcYNXI8fXgmGCwEyTvJqcuz 58MA3eJRdaLk09V9uR0WEZfTlKMZDlDdk86fIqa3q16PRBEgA3OUi4e37/GXWqbgcgNi GJq6bj8jAonbjIZhmhCz7857+e7YHYFMI9HoIqKYsQZkctMHMST+rjsFcKmO8eOwe3bc u8jEhkZplCYAarbd5p2sU0vNo2f2sFKy0eMJrfRxEUbNOAWTFGP7329Z5Snzbf15iWun FOQtIBFBBPGzNG5uNvGj7upzlpMOI/rqjD2GhKUuGLDR6ZNNh6L9ycFYL9zw37kyX9Z3 gzQA== X-Gm-Message-State: AOAM530GmJcL7xZwEuowcbdcCA/wONFqfu9qSxDfiNJVKsxZxluEQBW7 bHIsAwNEI/C4C3R5Nf5eKC/8WBjqyC0ED7k6eMFbz2h+I9nj1wAdDuY8gyq7dxJpffZtGlHZcLZ +yJBslLwcXxhSAi5kvcN/mkJV11wRt8sEpm8HyJIM X-Received: by 2002:ac8:5354:: with SMTP id d20mr15099338qto.321.1613406245638; Mon, 15 Feb 2021 08:24:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJwApc+CDGAxcv8ZeVQqTONvtUnu+7pjQddXPWqW57dXXgeKGYYXKqgxC64q4dPNta968wpdZg+o9qGxjtBntV4= X-Received: by 2002:ac8:5354:: with SMTP id d20mr15099320qto.321.1613406245370; Mon, 15 Feb 2021 08:24:05 -0800 (PST) MIME-Version: 1.0 References: <20210212143259.18712-1-viacheslavo@nvidia.com> In-Reply-To: From: Christian Ehrhardt Date: Mon, 15 Feb 2021 17:23:39 +0100 Message-ID: To: Viacheslav Ovsiienko Cc: dpdk stable , Michael Baum Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [PATCH 19.11] net/mlx4: fix device detach X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Mon, Feb 15, 2021 at 4:32 PM Christian Ehrhardt wrote: > > On Mon, Feb 15, 2021 at 1:20 PM Christian Ehrhardt > wrote: > > > > On Fri, Feb 12, 2021 at 3:33 PM Viacheslav Ovsiienko > > wrote: > > > > > > From: Michael Baum > > > > > > [ upstream commit 8e1630e0f1985beb7e48429e3a7614f4732b0e68 ] > > > > Thanks, added > > > > > When mlx4 device is probed, 2 different ethdev ports may be created for > > > the 2 physical ports of the device. > > > > > > Wrongly, when the device is removed, the created ports are not released. > > > > > > Close and release the ethdev ports in remove process. > > > > > > Bugzilla ID: 488 > > > Fixes: 7fae69eeff13 ("mlx4: new poll mode driver") > > > Cc: stable@dpdk.org > > > > > > Reported-by: David Marchand > > > Signed-off-by: Michael Baum > > > Acked-by: Matan Azrad > > > Tested-by: David Marchand > > > --- > > > drivers/net/mlx4/mlx4.c | 35 +++++++++++++++++++++++++++++++++++ > > > 1 file changed, 35 insertions(+) > > > > > > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c > > > index 4479022a4..3d2cef335 100644 > > > --- a/drivers/net/mlx4/mlx4.c > > > +++ b/drivers/net/mlx4/mlx4.c > > > @@ -376,6 +376,10 @@ mlx4_dev_close(struct rte_eth_dev *dev) > > > struct mlx4_priv *priv = dev->data->dev_private; > > > unsigned int i; > > > > > > + if (rte_eal_process_type() == RTE_PROC_SECONDARY) { > > > + rte_eth_dev_release_port(dev); > > > + return 0; > > > I've found on tests that this won't work. > Back in 19.11 this was a void function and therefore "return 0" breaks > on some rather strict compiler settings. > I'll make it just a "return;" but wanted to ask you to double check if > that should overall still work fine in your opinion. > > > > + } > > > DEBUG("%p: closing device \"%s\"", > > > (void *)dev, > > > ((priv->ctx != NULL) ? priv->ctx->device->name : "")); > > > @@ -1131,6 +1135,36 @@ mlx4_pci_probe(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev) > > > return -err; > > > } > > > > > > +/** > > > + * DPDK callback to remove a PCI device. > > > + * > > > + * This function removes all Ethernet devices belong to a given PCI device. > > > + * > > > + * @param[in] pci_dev > > > + * Pointer to the PCI device. > > > + * > > > + * @return > > > + * 0 on success, the function cannot fail. > > > + */ > > > +static int > > > +mlx4_pci_remove(struct rte_pci_device *pci_dev) > > > +{ > > > + uint16_t port_id; > > > + int ret = 0; > > > + > > > + RTE_ETH_FOREACH_DEV_OF(port_id, &pci_dev->device) { > > > + /* > > > + * mlx4_dev_close() is not registered to secondary process, > > > + * call the close function explicitly for secondary process. > > > + */ > > > + if (rte_eal_process_type() == RTE_PROC_SECONDARY) > > > + ret |= mlx4_dev_close(&rte_eth_devices[port_id]); Oh there is more, this ^^ will also not work with a void function. I'll dequeue the patch for now, please if you would re-spin your backport that would be nice. > > > + else > > > + ret |= rte_eth_dev_close(port_id); > > > + } > > > + return ret == 0 ? 0 : -EIO; > > > +} > > > + > > > static const struct rte_pci_id mlx4_pci_id_map[] = { > > > { > > > RTE_PCI_DEVICE(PCI_VENDOR_ID_MELLANOX, > > > @@ -1155,6 +1189,7 @@ static struct rte_pci_driver mlx4_driver = { > > > }, > > > .id_table = mlx4_pci_id_map, > > > .probe = mlx4_pci_probe, > > > + .remove = mlx4_pci_remove, > > > .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV, > > > }; > > > > > > -- > > > 2.18.1 > > > > > > > > > -- > > Christian Ehrhardt > > Staff Engineer, Ubuntu Server > > Canonical Ltd > > > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd