From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id BDB377D3A for ; Wed, 23 Aug 2017 11:40:47 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id f8so3743160wrf.3 for ; Wed, 23 Aug 2017 02:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=FYeszDbjNtFErO67z++7jXRBCP9tOxi356UXy3G8i5Q=; b=nel/nALfC5OMX0rn0BrTXwgIj6fv/9oR8VmrXVOjHOpbMRPZGEwe7+ViRbfqo9f+nN 1oZA7BW3sH/vj3yZWrb76wXGpUkPz/w5PVGgQJnXg5HS1wHfW/Wbbo7bOXyFAYvsnOuD 6j1x1HSr3f/5xhb0VEDyBOC5Zf+3QAGattajIPt/7U7tZ+N09iZcUk/gzKl8G+Fav2r4 Zl5NuP7Di4B9JX6y0nNCJt0DYvpr1mNWE0hhZtCFRcOPHabnPtpAA8+8JS3ovVocTQHp TEvj0QZHGZ+PhPyEgq5Ttp00xm7njX0oO3oVQ8V3VP490YeDBNiYCDrshOM0DA+VtcbL 3aBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=FYeszDbjNtFErO67z++7jXRBCP9tOxi356UXy3G8i5Q=; b=fj98cafYAmKvVWwz0cGFACkzr3cFbMD09l0Fevq/ApeohHJ9xzI7wLY8k4do457mey TQchjViSeSpp5ohGIti/XCXmPPLcPiguZMhooiNq/fNb0L9wG2nLG9H/1inzVaO9x5g+ Bn8jaxa1+zr8u4J0pnvZf+wCuPCTVPu/pQafKEPYQ3FTJC6xw6Cqkrxn5+xCa1rPPdZu SBDlioNqwaiAsbBwBuZExjN6rYd06u6WMQtB+54YY/YXtQ5Gy8ZqX+C3YapAx75IuIGQ eOmYAoW1INmKCZIZBlEOXt92YoH1I0TG/KGjQoOWgoOvpfgfGasMNcAIV3pkcVP9AxRc Rmkg== X-Gm-Message-State: AHYfb5iq7Rn/S830YbzIvQ0vFXv1U0WqVuFnMWi1Um5tW/vtpw/ebF1x 8xPd5w1Wfe9yRXOp/UeMrg== X-Received: by 10.223.158.143 with SMTP id a15mr1165388wrf.307.1503481247354; Wed, 23 Aug 2017 02:40:47 -0700 (PDT) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id 80sm1227637wml.23.2017.08.23.02.40.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 02:40:46 -0700 (PDT) Date: Wed, 23 Aug 2017 11:40:37 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Matan Azrad Cc: Adrien Mazarguil , dev@dpdk.org Message-ID: <20170823094037.GS12995@autoinstall.dev.6wind.com> References: <1502627112-53405-1-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1502627112-53405-1-git-send-email-matan@mellanox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 1/2] net/mlx5: support device removal event 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: Wed, 23 Aug 2017 09:40:47 -0000 Hi Matan, On Sun, Aug 13, 2017 at 03:25:11PM +0300, Matan Azrad wrote: > Extend the LSC event handling to support the device removal as well. > The Verbs library may send several related events, which are > different from LSC event. > > The mlx5 event handling has been made capable of receiving and > signaling several event types at once. > > This support includes next: > 1. Removal event detection according to the user configuration. > 2. Calling to all registered mlx5 removal callbacks. > 3. Capabilities extension to include removal interrupt handling. > > Signed-off-by: Matan Azrad > --- > drivers/net/mlx5/mlx5.c | 2 +- > drivers/net/mlx5/mlx5_ethdev.c | 100 +++++++++++++++++++++++++++-------------- > 2 files changed, 68 insertions(+), 34 deletions(-) > > Hi > This patch based on top of last Nelio mlx5 cleanup patches. > > diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c > index bd66a7c..1a3d7f1 100644 > --- a/drivers/net/mlx5/mlx5.c > +++ b/drivers/net/mlx5/mlx5.c > @@ -865,7 +865,7 @@ static struct rte_pci_driver mlx5_driver = { > }, > .id_table = mlx5_pci_id_map, > .probe = mlx5_pci_probe, > - .drv_flags = RTE_PCI_DRV_INTR_LSC, > + .drv_flags = RTE_PCI_DRV_INTR_LSC | RTE_PCI_DRV_INTR_RMV, > }; > > /** > diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c > index 57f6237..404d8f4 100644 > --- a/drivers/net/mlx5/mlx5_ethdev.c > +++ b/drivers/net/mlx5/mlx5_ethdev.c > @@ -1112,47 +1112,75 @@ mlx5_ibv_device_to_pci_addr(const struct ibv_device *device, > } > > /** > - * Link status handler. > + * Update the link status. > + * Set alarm if the device link status is inconsistent. Adding such comment should also comment about the issue this alarm is solving i.e. why the link is inconsistent and why the alarm help to fix the issue. > * > * @param priv > * Pointer to private structure. > - * @param dev > - * Pointer to the rte_eth_dev structure. > * > * @return > - * Nonzero if the callback process can be called immediately. > + * Zero if alarm is not set and the link status is consistent. > */ > static int > -priv_dev_link_status_handler(struct priv *priv, struct rte_eth_dev *dev) > +priv_link_status_alarm_update(struct priv *priv) The old name is more accurate, the fact we need to program an alarm is a work around to get the correct status from ethtool. If it was possible to avoid it, this alarm would not exists. > +{ > + struct rte_eth_link *link = &priv->dev->data->dev_link; > + > + mlx5_link_update(priv->dev, 0); > + if (((link->link_speed == 0) && link->link_status) || > + ((link->link_speed != 0) && !link->link_status)) { > + if (!priv->pending_alarm) { > + /* Inconsistent status, check again later. */ > + priv->pending_alarm = 1; > + rte_eal_alarm_set(MLX5_ALARM_TIMEOUT_US, > + mlx5_dev_link_status_handler, > + priv->dev); > + } > + return 1; > + } else if (unlikely(priv->pending_alarm)) { > + /* In case of link interrupt while link alarm was setting. */ > + priv->pending_alarm = 0; > + rte_eal_alarm_cancel(mlx5_dev_link_status_handler, priv->dev); > + } > + return 0; > +} > + >[...] > > @@ -1172,11 +1200,11 @@ mlx5_dev_link_status_handler(void *arg) > priv_lock(priv); > assert(priv->pending_alarm == 1); > priv->pending_alarm = 0; > - ret = priv_dev_link_status_handler(priv, dev); > + ret = priv_link_status_alarm_update(priv); It is not clear, this calls an alarm_update without getting the link status, the function name is "link_status_handler" why does the behavior does not reflect the function name? It is too confusing to be integrated as is, we had several bugs in this part of the code, keep it clear, by keeping the old functions name. Thanks, -- Nélio Laranjeiro 6WIND