From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shahaf Shuler Subject: Re: [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses Date: Thu, 22 Mar 2018 07:44:51 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: =?iso-8859-1?Q?N=E9lio_Laranjeiro?= , "Adrien Mazarguil" , Yongseok Koh Return-path: Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00066.outbound.protection.outlook.com [40.107.0.66]) by dpdk.org (Postfix) with ESMTP id 9F746AAEC for ; Thu, 22 Mar 2018 08:44:55 +0100 (CET) Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thursday, March 22, 2018 9:35 AM, Shahaf Shuler: > Hi Nelio, >=20 > 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 trus= ted. > > > > 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 Sorry sent to early.=20 Another general question - is there required netlink version exists on all = the relevant distros? What is the minimal kernel version required?=20 > > @@ -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); >=20 > I think the two below should be introduced only on the next patch of the > series. >=20 > > +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_ */ >=20 > [...] >=20 > > +/** > > + * 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 =3D { .addr_bytes =3D { 0 }, }; > > + > > + for (i =3D MLX5_MAX_MAC_ADDRESSES - 1; i >=3D 0; --i) { > > + struct ether_addr *m =3D &dev->data->mac_addrs[i]; > > + > > + if (memcmp(&mac_null, m, ETHER_ADDR_LEN)) > > + mlx5_nl_mac_addr_remove(dev, m); > > + } > > +} >=20 > What if the DPDK process is terminated ungracefully? I think the MAC tabl= e > will remain with all the MACs which were added. > The next run of the process may have un-expected results. >=20 > Should we flush the neighbor mac table also on probe to make sure only th= e > VF mac exists? >=20 > > -- > > 2.11.0