From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 734294C7C for ; Thu, 22 Mar 2018 10:05:35 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id l9so14485032wmh.2 for ; Thu, 22 Mar 2018 02:05:35 -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=QQS6XyC3lsNlpljNGlvTKLmGMt9O7X82YHLWcAzKFQE=; b=vz13UroIHsDRk1qP0EFQtDFJnjgouAkuRu2PuztevW/DEoFXirzOBoXhdUq65QoQks iBqAEH6lBLtG3KrmtbU0jh8qhD9qF6ycNecifASVuNOr5MAHdXqqVxiCfgMozSZaYPPL +mYaOCYl/NkyVYH8Ajp16qCVTI1KDxqIQ+LnXVOxjYfzLw/JEr/qudeWW6B0awG4PMqb f3JBPwVb5ZTdndx4P2Sf0jC1HZzhoHx/DGH2ufHRWOKFejQVbQ8YyNjdxk39gGZgXVC+ e+GfyA5q9vHC0qLwxq8IrksDp6TfOIKEze0zFWNqzytTsWmScKuQGyxDurwxhe07DN6Y OaiA== 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=QQS6XyC3lsNlpljNGlvTKLmGMt9O7X82YHLWcAzKFQE=; b=p0oE3FRsibQPkA6MMzvDh9vnu1yfURjr3EKI9wVsuxbg3CrOFc2PkGf71xQvOchTAh J3NrhKWOx/NnWVByu4sDH6ylDYL/Wsds4wsb0sI8BSD9rblQL6ManbNpwTdrBdfW5rsY KSCdTvhQX848dTAEg3wTsjeW12kZ1Xe3XBKia4eNmCDlnUjUF0EjKqeTKIpBaRrCVPUV 8zPInwJHnqZ82XN/zY9/j2qVDL1bOnOezIfZR+1qLXZnOAPT0EgSCS5mde8PGABvV2CX A0o+3ND2C/gUoGM7tHEOIhC++AmoxGbl063P5DsqassIO+1XYPHBEYI7Ws46sj/8jRKJ ZU/A== X-Gm-Message-State: AElRT7Fc2yaAqXiau5XMRhAkecTDLf2Y6LS4Stw91lGILzb3ZWqCXUeX arI/nTI06l3QbYI56ZFn7wZk X-Google-Smtp-Source: AG47ELvZumC6L1s9IdNmExhNQE6U+kPs5eNVkrAPiknTGggPBEGN9BBBf2IRW9AojpeaHLJ53CIrgA== X-Received: by 10.28.160.9 with SMTP id j9mr5230704wme.51.1521709535120; Thu, 22 Mar 2018 02:05:35 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id w69sm4413188wrb.94.2018.03.22.02.05.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Mar 2018 02:05:34 -0700 (PDT) Date: Thu, 22 Mar 2018 10:04:45 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Shahaf Shuler Cc: Adrien Mazarguil , Yongseok Koh , "dev@dpdk.org" Message-ID: <20180322090445.63pcs6jwljdob6pi@laranjeiro-vm.dev.6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses 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: Thu, 22 Mar 2018 09:05:35 -0000 On Thu, Mar 22, 2018 at 07:34:50AM +0000, Shahaf Shuler wrote: > Hi Nelio, > > Wednesday, March 21, 2018 3:40 PM, Nelio Laranjeiro: > > VF devices are not able to receive traffic unless it fully requests it though > > Netlink. This will cause the request to be processed by the PF which will > > add/remove the MAC address to the VF table if the VF is trusted. > > > > Signed-off-by: Nelio Laranjeiro > > Acked-by: Adrien Mazarguil > > --- > > drivers/net/mlx5/Makefile | 1 + > > drivers/net/mlx5/mlx5.c | 22 ++ > > drivers/net/mlx5/mlx5.h | 13 + > > drivers/net/mlx5/mlx5_ethdev.c | 27 +++ > > drivers/net/mlx5/mlx5_mac.c | 25 +- > > drivers/net/mlx5/mlx5_nl.c | 530 > > +++++++++++++++++++++++++++++++++++++++++ > > diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index > > faacfd9d6..6a7e9f310 100644 > > --- a/drivers/net/mlx5/mlx5.h > > +++ b/drivers/net/mlx5/mlx5.h > > @@ -78,6 +78,7 @@ struct mlx5_dev_config { > > unsigned int hw_vlan_strip:1; /* VLAN stripping is supported. */ > > unsigned int hw_fcs_strip:1; /* FCS stripping is supported. */ > > unsigned int hw_padding:1; /* End alignment padding is supported. > > */ > > + unsigned int vf:1; /* This is a VF. */ > > unsigned int mps:2; /* Multi-packet send supported mode. */ > > unsigned int tunnel_en:1; > > /* Whether tunnel stateless offloads are supported. */ @@ -154,6 > > +155,8 @@ struct priv { > > struct mlx5_dev_config config; /* Device configuration. */ > > struct mlx5_verbs_alloc_ctx verbs_alloc_ctx; > > /* Context for Verbs allocator. */ > > + int nl_socket; /* Netlink socket. */ > > + uint32_t nl_sn; /* Netlink message sequence number. */ > > }; > > > > /* mlx5.c */ > > @@ -163,6 +166,7 @@ int mlx5_getenv_int(const char *); > > /* mlx5_ethdev.c */ > > > > int mlx5_get_ifname(const struct rte_eth_dev *dev, char > > (*ifname)[IF_NAMESIZE]); > > +int mlx5_ifindex(const struct rte_eth_dev *dev); > > int mlx5_ifreq(const struct rte_eth_dev *dev, int req, struct ifreq *ifr); int > > mlx5_get_mtu(struct rte_eth_dev *dev, uint16_t *mtu); int > > mlx5_set_flags(struct rte_eth_dev *dev, unsigned int keep, @@ -297,4 > > +301,13 @@ struct mlx5_mr *mlx5_mr_get(struct rte_eth_dev *dev, struct > > rte_mempool *mp); int mlx5_mr_release(struct mlx5_mr *mr); int > > mlx5_mr_verify(struct rte_eth_dev *dev); > > > > +/* mlx5_nl.c */ > > + > > +int mlx5_nl_init(uint32_t nlgroups); > > +int mlx5_nl_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr > > +*mac); int mlx5_nl_mac_addr_remove(struct rte_eth_dev *dev, struct > > +ether_addr *mac); void mlx5_nl_mac_addr_flush(struct rte_eth_dev > > *dev); > > I think the two below should be introduced only on the next patch of the series. Right, > > > +int mlx5_nl_promisc(struct rte_eth_dev *dev, int enable); int > > +mlx5_nl_allmulti(struct rte_eth_dev *dev, int enable); > > + > > #endif /* RTE_PMD_MLX5_H_ */ > > [...] > > > +/** > > + * Flush all added MAC addresses. > > + * > > + * @param dev > > + * Pointer to Ethernet device. > > + */ > > +void > > +mlx5_nl_mac_addr_flush(struct rte_eth_dev *dev) { > > + int i; > > + const struct ether_addr mac_null = { .addr_bytes = { 0 }, }; > > + > > + for (i = MLX5_MAX_MAC_ADDRESSES - 1; i >= 0; --i) { > > + struct ether_addr *m = &dev->data->mac_addrs[i]; > > + > > + if (memcmp(&mac_null, m, ETHER_ADDR_LEN)) > > + mlx5_nl_mac_addr_remove(dev, m); > > + } > > +} > > What if the DPDK process is terminated ungracefully? I think the MAC > table will remain with all the MACs which were added. > The next run of the process may have un-expected results. > > Should we flush the neighbor mac table also on probe to make sure only > the VF mac exists? In such situation the sysadmin should make the clean up, the DPDK application cannot consider it is the only one using the device as it is not the case, Linux still owns the device. We have no guarantee the admin did not use another MAC address for a service outside of the DPDK application (even if in such case he should disable this feature to fully control what happens on the neighbor mac table). Thanks, -- Nélio Laranjeiro 6WIND