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 048D6A0352; Mon, 14 Feb 2022 18:54:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF2A340DDA; Mon, 14 Feb 2022 18:54:12 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 132F84067E for ; Mon, 14 Feb 2022 18:54:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644861251; x=1676397251; h=message-id:date:to:references:from:subject:in-reply-to: content-transfer-encoding:mime-version; bh=oySXLVqtfqygw69tbxK7h8CrqTiM3pEV7YJ2tQS08c4=; b=JLFF5QjbYrb+tms60iZXYSOnvqcjW/csqYOIPsAEiXwGGLnM8kxXaRqu hbccf0LK38rHwCH2gsXehb9f2Jg1HDZzEZaeBYOfsC9qdyDUsLqA/cueG xdTZ8Vlkt95D1K/frxnt7XDvlb300FxiuT2oMf00HhUPEjwa6m6UnWGrw y/uBCpadDT7AHW2f2Z9oUUGaoPGRsK3vQBh4w2EXuG8ZIxqbvfOLxWNaX XnP5l5NSu72AA8xIVqeeCIDyXIXF89Bt5jXmweRPlN23rjkKMOU3guX59 ke5hrUU1ZLMYBUPpLV9Dz3PD5Ab4aNsfOXl1rd/R6npXMWqQkisfE7LUk Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="248980906" X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="248980906" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 09:54:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,368,1635231600"; d="scan'208";a="570343064" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga001.jf.intel.com with ESMTP; 14 Feb 2022 09:54:09 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 14 Feb 2022 09:54:09 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Mon, 14 Feb 2022 09:54:09 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Mon, 14 Feb 2022 09:54:08 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dbh56pmndTh9mn6DFqxxney7ZVW0nhVQuJu0mGgUwNl5b58/fqjSDGC6fDa+2bZjMt74aFZO2LBFIBjfJz8x0RSoPQthDdDYHlOOjSxLg6RU8WinJz6VIKKp0zdv2VbZdZKQmYYpKYEvUq/Pug29X/WF6mxvmtRFpvcsTULdZJDT/eez1cCnmWlrj4mBZabuLVv0ktet91m3IAB0txb+rrXbzu2wM+AgQXY1Cf/04u1VjnQd50HQ7l7r4aL5XFDFnmsS2KzcZXk+p9reDpLnZYTnGqk7lgQTfRdAAAtiMLJAVIvk2TaexwaG00ynElCm3k5qN00bjynXk5eb7A1yHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Q0StRyA8j6qE+jgHaAr0NeImiuMUlO+/2uUjH0i2KNY=; b=lQovi58nWOllaL8wsbthzYyBwVwcaGLbc1igBNoU1tjT/c3JQfCRDgnFYj3l0i3zzIeSr4nLKWaIt8ZVmq+4pG21sn69I+ZHX0liGm97iKVau7SqHBwJXPYfDB8M5AsT0d4ygI4w1o0snxinSWdAqIIcKhSC+yzYxhxd+BivTmtcP8fjXn+AYbQaFPLiHXROZSiYXwtyjFfNr+OZ+KDbkzf3ODbhfdUq588eR0WmtZqw2cnOaPbkdVqnWy1TIeDJ16/ycPAnJ6n5JO2bUquVGEbJ20oqsmTqloGK2i8YF5WMvjpGIMFtLoa2bOu/kCW9SdrokDIGbEeOI66eIoznEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by MN2PR11MB3903.namprd11.prod.outlook.com (2603:10b6:208:136::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.17; Mon, 14 Feb 2022 17:54:07 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::98be:5506:5020:28a2]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::98be:5506:5020:28a2%4]) with mapi id 15.20.4975.019; Mon, 14 Feb 2022 17:54:07 +0000 Message-ID: <5610fc4b-d92c-363a-98e7-3d82ddc30277@intel.com> Date: Mon, 14 Feb 2022 17:54:02 +0000 Content-Language: en-US To: Martin Spinler , References: <20220214112541.29782-1-spinler@cesnet.cz> <20220214112541.29782-6-spinler@cesnet.cz> <2aa9023f3d44d286b9d5ba105e3a9bbc456416f6.camel@cesnet.cz> From: Ferruh Yigit Subject: Re: [PATCH 6/6] drivers/nfb: add support for more MAC addresses X-User: ferruhy In-Reply-To: <2aa9023f3d44d286b9d5ba105e3a9bbc456416f6.camel@cesnet.cz> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0033.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::21) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b07cadb3-e1f1-4b05-b72d-08d9efe2feeb X-MS-TrafficTypeDiagnostic: MN2PR11MB3903:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Kl3EzXcrjs8dLJamiSyid/G+ZWYo9GaDswwKeUH3NgOmXO5QzQni3TxctoXVo2ZGLCGUV6fwd8qPhWfRtKuC7rUxbdNyaaJu4KtfxcAO/tlLikOZ+K8k5LtQjdCf6YHNdfJ2J/m56RiVzta4WOd+jCc6MGUPxlxn0ts+UsZs7vyCxyFluj8aJ6y2HoYVlDC/mjoH82yllk54IvwKLGTAKBmI/N5PKca2fA6YsDLr1RRe9JJ7XT6quqKgF/oL6pTy1UCtw/d6AneWb/VLTyfj/ngJNGOZUdQybRemTBs1GMtMx5+iSZYQHrZ+fmdhW2JgOabUi6QSIhsxtfry+o4Sl9ifLHjKdA3TupeH1F5+2NSzecdi8WPQr4reGcgWMZZoy8asAtodpsgXFzrQLUv2LY+cqh2n4SEEm0uHEH2OcEwCKR3VUiNOK+bD9JlC5UjPumIokyB9LwJ3Wqmakmgy2jnqaiOa3TJ6aG2dxWxAqdYL+mT2kXbLy1pvzcBmW32aAcITqus7G6kNB50n0lwTGo0VMwhBmwoCDGWLFguluDmXvfg0NSwNLzhuRpvOS4zuJ2qls9RdyDR0DzBsaIw47btJ8wtTP7AcUX5wl/nJbrpUk+K0YJW0vTRU82jR7OHTNPeoM5WdOIz+Rrbrpi80CeydoSV2Ce9JKQbGCIuR05p0aFKll78/98gZGCey2rOl9Hqzv7tV8EpDjS1rAsmc+A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(2906002)(5660300002)(82960400001)(83380400001)(6512007)(186003)(316002)(66476007)(66556008)(66946007)(26005)(6486002)(508600001)(44832011)(53546011)(8676002)(6506007)(31686004)(31696002)(38100700002)(36756003)(86362001)(8936002)(6666004)(2616005)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eExWaWtyVFBha3Zic1JxcVU0OEdoR3IwTU1WeHRiMHJXeC81WEFya3FISkEv?= =?utf-8?B?bUVUclNMOXhTbU9hYjBqK3l5TVJWLzY4WmxuK1YremxicVREQjVKSElZcUox?= =?utf-8?B?aklHTSsxOE1RNnl2Q0lkVVk4UVhZdTByOVN6aXJmemttOGtXb2hma2p6QlVm?= =?utf-8?B?OGxIcm01L2pwdC9FOUdLOUI0bzExa0VvdDB5QkoyMmhpZUdmWmw1MGovc0tE?= =?utf-8?B?V1ZWcTBwdlM1M25GazFGWU1WQTNIRlc5eFJuTzNpK2JJNU5nU1prTFpvRkhT?= =?utf-8?B?YzViUUtrV1h4eGZQVGxHNHRZQVRwV28wNjdXbzZZMCtCSWtERDBTTUQ4cDdX?= =?utf-8?B?OUwwenJWaXlqZ3ZBOWlZY21Yd0ZEdXdNSWh6Ti9KdTg5TjhpNHB5Qk8vRlVC?= =?utf-8?B?K0t4OUVQQ29rWWJ6ZjRNTmRldG9JcmpDbmJDaEI3Mlp6V2JHd2E2RzVCUHYw?= =?utf-8?B?dU5JUDRBY2EyVm1PVFZBN3U1OFJvazlnc1c3cnN0dm90UGJJSUZtQzVpRDhW?= =?utf-8?B?ZEFzZ0dud0FvajJNcjBEWVpBN21ycUFiWmE4cktUcGxCYkowYUxzUm1Md3Jm?= =?utf-8?B?T3lwYUlNV2pqTERubURpdVNRdzZoU0hxYWdUSmFGRWdUOS9aUGRSSElNNjhB?= =?utf-8?B?YnpZeDlUQWFmM24yaFZDYWdNNWpNWFNxNmFOdmx6aGg4dWRiUG1haDYyNEUw?= =?utf-8?B?YVZWMmNjc0R3UXFjNDliUnBzNHZCTkdBT2gwS1pHSXR1cEt5U0o5MDUrN3JD?= =?utf-8?B?c2habm03djR6bjRTbjY3VmlvT2ZtaUlmSExBSWxYK09xZUYyaWRVZXJOeko4?= =?utf-8?B?TVBlL2hyUUprTTU4NHNhVEJRTmtHVDJqc2ZBd0gvTmdYL3NTVk1sem9wektL?= =?utf-8?B?NFJWRjJxVnl6ZDRPMVdpcjRJb240UERLNHFURWdRemJaaGRjMEpwcFpyRitR?= =?utf-8?B?UVNxUXE4akc4NFBqa0ZwaTZxSWJzMzhZS28wUXBWdkQ1RXhJZ01waG5RL0x6?= =?utf-8?B?ZFVFMklnODFZZ21rWTh3Vkk3WTRCcExmbDJHYmFXYldSNW1iVEhhQXNxbnE1?= =?utf-8?B?LytOVlZFOHRNUU9mWno0K25kNm9UbTVyZWl4M1FpYmJBUlA1d09NK1NoalJI?= =?utf-8?B?ejdmaUIvOHhpREpwems2eUs3NVZSdzQwMFg4cEMzUWdyYXF6UytBMmRjRGRx?= =?utf-8?B?SlFJUnQ5TkFNSkJ4dHI4ZFdOT0Eyb0IzOXRlS2xob1l6Y0JMdXpTYkJuQWZs?= =?utf-8?B?bjNQY2NuRTR5empaMEUrcmxDOG83ZmZHOHVGQjUxZTNFemhiNk4xRXVBYldz?= =?utf-8?B?M3Z1SHZiaDhPZUs3elN1NXB4eHNHSG0zVWNmcHFxaGtOTGV6TGtpK2JsM2Y2?= =?utf-8?B?S1NwRWMrdDdxSHBvK2gxZmxTaHUvd0N1MnlCdGdZQmgzdEtoS0VYWGtrelRT?= =?utf-8?B?RHZndlpQZ3h6R2o5ZGRzbm4vYUNTdzJ2NEMzb1FPZXpMdWQvYVJKVzJkU2FH?= =?utf-8?B?OWpyVTRxbFI1cUFmY1JvUHMxYWZFdm00cVNyK2YrY01wTWlMM3hNWkFrN1Rl?= =?utf-8?B?RjVzazVBSDd2TWpqbFRCMzltNnBOU1BBd01velU4ckN4eWY1dFNVaGFQUE4r?= =?utf-8?B?dEQ1WlAybWZJZGliaUhPWmRMNVlybzJudXlnaDRINzkzZGRZNEdGbWhlMytx?= =?utf-8?B?OUh3ZXh2bEFINHZmSDQ2b0VRNnBjcmpTbnA5N2FmU3ZxNURnamFhQ3NxQk5O?= =?utf-8?B?RzRQcUwvdTIwaGd3RWlzZUcybDRybnJmQldsVm14enFrYXFQYVNNaVVYa1FT?= =?utf-8?B?KzNCM09PUU02TWhXTGlZM1JaU3gyNjFlSHFCS2U3bWFQSmcwRG9kRHZFdFZt?= =?utf-8?B?MVU2MGRJWlZsR3lzWVVZRHFKL2VVZ001bWNPWkNLbkgvYjA0cjJNZ3VGTklK?= =?utf-8?B?V240dHlZbHVyMDFWTFc3Wll6dUZJVEIyZjRRN1FEL2NqQnpkdXo2aVdTWmdw?= =?utf-8?B?TDM5N3VnamZ4UjJWcDdjNklOeDNGWUlGdUJBZkp3WW9ldE1xRWNOM25UQ2xk?= =?utf-8?B?OWQ0S09nclVUQVdiUGRjU1NnNTRYNU5lNk5aQ2JWOXIyTHNCb3dPWUx3bGZ2?= =?utf-8?B?R0daOXVUcm9tZVIrdVFYNURaMi9BSVJoQTRhcGdZb1QvUEpRRHoxbEs4ZXJV?= =?utf-8?Q?C5I5e398lC9v6fs3jT1S/vg=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: b07cadb3-e1f1-4b05-b72d-08d9efe2feeb X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2022 17:54:07.0330 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pz7rpVzVXwRRta+Dh12VfTjXkWpknN4od1xmpWPBe2Yfm/xgaKJhAZZ59uSMLtqg5PAkL5QlOXOnoWYI4PoLeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3903 X-OriginatorOrg: intel.com 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 2/14/2022 4:53 PM, Martin Spinler wrote: > On Mon, 2022-02-14 at 13:37 +0000, Ferruh Yigit wrote: >> On 2/14/2022 11:25 AM, spinler@cesnet.cz wrote: >>> From: Martin Spinler >>> >>> Extend the eth_dev_ops by add/remove MAC address functions. >>> >>> Signed-off-by: Martin Spinler >>> --- >>> drivers/net/nfb/nfb_ethdev.c | 69 ++++++++++++++++++++++++++++++------ >>> 1 file changed, 58 insertions(+), 11 deletions(-) >>> >>> diff --git a/drivers/net/nfb/nfb_ethdev.c b/drivers/net/nfb/nfb_ethdev.c >>> index 5d503e131a..7dec8e022e 100644 >>> --- a/drivers/net/nfb/nfb_ethdev.c >>> +++ b/drivers/net/nfb/nfb_ethdev.c >>> @@ -214,7 +214,19 @@ static int >>> nfb_eth_dev_info(struct rte_eth_dev *dev, >>> struct rte_eth_dev_info *dev_info) >>> { >>> - dev_info->max_mac_addrs = 1; >>> + uint16_t i; >>> + uint32_t max_mac_addrs; >>> + struct pmd_internals *internals = dev->data->dev_private; >>> + >>> + dev_info->max_mac_addrs = (uint32_t)-1; >>> + for (i = 0; i < internals->max_rxmac; i++) { >>> + max_mac_addrs = nc_rxmac_mac_address_count(internals->rxmac[i]); >>> + dev_info->max_mac_addrs = RTE_MIN(max_mac_addrs, >>> + dev_info->max_mac_addrs); >>> + } >>> + if (internals->max_rxmac == 0) >>> + dev_info->max_mac_addrs = 0; >>> + >> >> Not sure if 'max_mac_addrs = 0' is valid value, as far as I can see >> driver allocates memory for at least one MAC address, so there is no >> case that NIC doesn't support any MAC address. > > Oh, sorry, I missed that, will be fixed in v2. > >> >> It looks like max_mac_addrs usage is not clear, what is exactly the >> 'max_rxmac' & 'rxmac[]' variables are? > > rxmac is a firmware unit which represents the RX side of one physical > Ethernet port (more precisely one logical Eth channel on port) and > handles stats+CRC check+MAC filtering. So this goes through all those > units and finds the rxmac with minimal memory space for MAC addresses > and uses this value. > Got it. > I'll add few comments in the code to v2. > Thanks. >> >>> dev_info->max_rx_pktlen = (uint32_t)-1; >>> dev_info->max_rx_queues = dev->data->nb_rx_queues; >>> dev_info->max_tx_queues = dev->data->nb_tx_queues; >>> @@ -376,6 +388,18 @@ nfb_eth_dev_set_link_down(struct rte_eth_dev *dev) >>> return 0; >>> } >>> >>> +static uint64_t >>> +nfb_eth_mac_addr_conv(struct rte_ether_addr *mac_addr) >>> +{ >>> + int i; >>> + uint64_t res = 0; >>> + for (i = 0; i < RTE_ETHER_ADDR_LEN; i++) { >>> + res <<= 8; >>> + res |= mac_addr->addr_bytes[i] & 0xFF; >>> + } >>> + return res; >>> +} >>> + >>> /** >>> * DPDK callback to set primary MAC address. >>> * >>> @@ -392,26 +416,47 @@ nfb_eth_mac_addr_set(struct rte_eth_dev *dev, >>> struct rte_ether_addr *mac_addr) >>> { >>> unsigned int i; >>> - uint64_t mac = 0; >>> + uint64_t mac; >>> struct rte_eth_dev_data *data = dev->data; >>> struct pmd_internals *internals = (struct pmd_internals *) >>> data->dev_private; >>> >>> - if (!rte_is_valid_assigned_ether_addr(mac_addr)) >>> - return -EINVAL; >>> + mac = nfb_eth_mac_addr_conv(mac_addr); >>> + for (i = 0; i < internals->max_rxmac; ++i) >>> + nc_rxmac_set_mac(internals->rxmac[i], 0, mac, 1); >> >> This functions is to set default MAC address 'data->mac_addrs[0]', >> why same MAC set multiple times in a loop? > > Unfortunately, currently we don't have firmware support for proper > separate port configuration, because DMA queues aren't bound to > specific rxmac and traffic can be mixed between them. So I think the > best way in this case is to write the same MAC address into all of the > rxmacs inside firmware. > I see the usage now, that looks OK. >> >>> >>> - for (i = 0; i < RTE_ETHER_ADDR_LEN; i++) { >>> - mac <<= 8; >>> - mac |= mac_addr->addr_bytes[i] & 0xFF; >>> - } >>> + return 0; >>> +} >>> >>> +static int >>> +nfb_eth_mac_addr_add(struct rte_eth_dev *dev, >>> + struct rte_ether_addr *mac_addr, uint32_t index, uint32_t pool __rte_unused) >>> +{ >>> + unsigned int i; >>> + uint64_t mac = 0; >>> + struct rte_eth_dev_data *data = dev->data; >>> + struct pmd_internals *internals = (struct pmd_internals *) >>> + data->dev_private; >>> + >>> + mac = nfb_eth_mac_addr_conv(mac_addr); >>> for (i = 0; i < internals->max_rxmac; ++i) >>> - nc_rxmac_set_mac(internals->rxmac[i], 0, mac, 1); >>> + nc_rxmac_set_mac(internals->rxmac[i], index, mac, 1); >>> >>> - rte_ether_addr_copy(mac_addr, data->mac_addrs); >>> return 0; >>> } >>> >>> +static void >>> +nfb_eth_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index) >>> +{ >>> + unsigned int i; >>> + struct rte_eth_dev_data *data = dev->data; >>> + struct pmd_internals *internals = (struct pmd_internals *) >>> + data->dev_private; >>> + >>> + for (i = 0; i < internals->max_rxmac; ++i) >>> + nc_rxmac_set_mac(internals->rxmac[i], index, 0, 0); >>> +} >>> + >>> static const struct eth_dev_ops ops = { >>> .dev_start = nfb_eth_dev_start, >>> .dev_stop = nfb_eth_dev_stop, >>> @@ -436,6 +481,8 @@ static const struct eth_dev_ops ops = { >>> .stats_get = nfb_eth_stats_get, >>> .stats_reset = nfb_eth_stats_reset, >>> .mac_addr_set = nfb_eth_mac_addr_set, >>> + .mac_addr_add = nfb_eth_mac_addr_add, >>> + .mac_addr_remove = nfb_eth_mac_addr_remove, >>> }; >>> >>> /** >>> @@ -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? >> >>> data->promiscuous = nfb_eth_promiscuous_get(dev); >>> data->all_multicast = nfb_eth_allmulticast_get(dev); >> >