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 50550A00C5; Tue, 15 Feb 2022 14:02:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3B69941172; Tue, 15 Feb 2022 14:02:07 +0100 (CET) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by mails.dpdk.org (Postfix) with ESMTP id 09BBA4115E for ; Tue, 15 Feb 2022 14:02:06 +0100 (CET) Received: from [IPv6:2001:67c:1220:80c:eb:e00e:9e81:ff5f] (unknown [IPv6:2001:67c:1220:80c:eb:e00e:9e81:ff5f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id C6A7E40006C; Tue, 15 Feb 2022 14:02:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2-2020; t=1644930125; bh=+cslBiT494gnrEwZReW9m2qLDKtN4VUgy7G3L+GtBtA=; h=Subject:From:To:Date:In-Reply-To:References; b=BKEyPDbbPcIn6wB1IdYHf7SwLwwtE0RypKNM8dXTKMlzu4UeuvG9a0/1ArWYHf0W1 QoYV1LRMCpxOHW1YLCzflJV9fb8iA89jRDgDR0sNTXrF2yxMvhQmcpavqnTk0Xi9Cm m8/FX3vqVaP7bCzmR+OxRVHZUD/v8ONxOMJZdbA2IwzqehFd9ZJiR18n6gyNI3c7rk F9XQJAWxR/D7OBp7JteXBZUyK3k84eF5SE8wx8CGK/yZ26gX2Vmov9/BYA02t2N3WO FJaGUC9gIr5x/ejp6Z5uiF9UvthKd3fjdZQGNy8DH8pX8FQfgHV7Tz8j1MrV0IOYIt Z849K/QQxR4mA== Message-ID: <225e84bd2655bd006ba1478fae68c40d043190d3.camel@cesnet.cz> Subject: Re: [PATCH 6/6] drivers/nfb: add support for more MAC addresses From: Martin Spinler To: Ferruh Yigit , dev@dpdk.org Date: Tue, 15 Feb 2022 14:02:05 +0100 In-Reply-To: <5610fc4b-d92c-363a-98e7-3d82ddc30277@intel.com> References: <20220214112541.29782-1-spinler@cesnet.cz> <20220214112541.29782-6-spinler@cesnet.cz> <2aa9023f3d44d286b9d5ba105e3a9bbc456416f6.camel@cesnet.cz> <5610fc4b-d92c-363a-98e7-3d82ddc30277@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 2022-02-14 at 17:54 +0000, Ferruh Yigit wrote: > > > > @@ -530,7 +577,7 @@ nfb_eth_dev_init(struct rte_eth_dev *dev) > > > >      eth_addr_init.addr_bytes[1] = eth_addr.addr_bytes[1]; > > > >      eth_addr_init.addr_bytes[2] = eth_addr.addr_bytes[2]; > > > >     > > > > - nfb_eth_mac_addr_set(dev, ð_addr_init); > > > > + rte_eth_dev_default_mac_addr_set(dev->data->port_id, > > > > ð_addr_init); > > > >     > > > > > > I didn't get this change, why calling the API from the driver, > > > instead of calling the dev_ops directly as original code did? > > > > The API does all the checks and copies the MAC value into internal > > data > > struct, so our code was duplicit. I didn't realize that calling the > > API > > could be problem. I assume it should be reverted to the prev form? > > > > It is not a problem, and APIs are used because of the reason you > mentioned in a few places, but for this case I didn't get it, > what API check is required? > Is it 'rte_is_valid_assigned_ether_addr()' check? The mac in this > function ('nfb_eth_dev_init()') is a hardcoded one, instead of > validity check, why not select a valid MAC at this stage? > > I mean still drop the 'rte_is_valid_assigned_ether_addr()' check > from 'nfb_eth_mac_addr_set()', but be sure 'eth_addr_init' is > valid MAC, will it work? Yes, definitely a better way. Just rte_ether_addr_copy remains. > > > > > > > >      data->promiscuous = nfb_eth_promiscuous_get(dev); > > > >      data->all_multicast = nfb_eth_allmulticast_get(dev); > > > > >