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 C3D58A0C47; Tue, 26 Oct 2021 12:22:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9E642410D5; Tue, 26 Oct 2021 12:22:10 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 1A41F407FF for ; Tue, 26 Oct 2021 12:22:07 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10148"; a="229818104" X-IronPort-AV: E=Sophos;i="5.87,182,1631602800"; d="scan'208";a="229818104" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Oct 2021 03:22:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,182,1631602800"; d="scan'208";a="465262757" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga002.jf.intel.com with ESMTP; 26 Oct 2021 03:22:06 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 26 Oct 2021 03:22:06 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) 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.2242.12; Tue, 26 Oct 2021 03:22:05 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 26 Oct 2021 03:22:05 -0700 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.40) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 26 Oct 2021 03:22:05 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZYyxfNn5Tg3SK7ZSvug4si5WsLX09dfutKl+4HIUfx5IAShkLWRrxJdqPqPJIzYRYFA2S5CdCMIu25f87aIG5FboMmeZZgf8k0nyjn9XV6Jm+3CSnbGLN9eknU6Y3+5wgyCFdmgoZ+EypmgdvGNUkIDJ91uf+LBBism2zufuyMwV5zBkolGyGxEr4joNJqdXfLGn/U6VhtskDfn+g6kaz3ZrvArz7mVSwElDtaW84mRtdTLGWIIijmhODHoy8RvBQ17R+BpVx9OZP6brJzUCczsfdNxp92Nu+c4/A9dctCkSlSzcSxmdbv2BwYWfKsDTm3AyaiUkA1fU9dE5kIeRjQ== 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=FEz80e2Zfpzmyj9YDML4ejNCH3nGNY6An+3Aswg6Dos=; b=hCA2z9KkuDgEt0CwyT5oE92SJLM4AfJ65/ot03s9xwV5xZkLEUlSZO+Gu7UMCvTUzKDxjLeJpJzJgq0fpSIUOfDdAiNxenWQU1j2KpDNk5ZSq1AdoBBeHlCK5Ld01HPUF4PgXX/VHiMEYmzUlNF+6iv8zgQquZ8v5bh18yITWa3Gw4+VSHDGyf96GyawxXhSe9noajh1s8Z2O5NBpZJMYfqU2COtgotVuaQHZiLMpBoWNVemav7UoG3bZPoAj3I2BO87GUuUQ+A/coRawXIkjoVzhNBOSkOEwLy+6hQ3JIwLR/qEdMW5G4kpTCBf/HhEeGv+4wY+0RRkyJuO1NfTJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FEz80e2Zfpzmyj9YDML4ejNCH3nGNY6An+3Aswg6Dos=; b=jIfyV4CQNtStMXzN2gZRtdcPXwz1OcFhEmkFwN6RBKXhoSJ8+WOK4Fem2TYKsNBYP81mZcTo7yoa6YAICgPnGIS/Xcs7G+xUTV9Fb9zLAVVG2aX7AmPqw0UrHM3g+YFVPU92twMrzRZpjG+SSt1/eQukzXm2osL9g4cU4Wj0zrE= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH7PR11MB5914.namprd11.prod.outlook.com (2603:10b6:510:138::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Tue, 26 Oct 2021 10:22:04 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::bd7d:29be:3342:632c%6]) with mapi id 15.20.4628.020; Tue, 26 Oct 2021 10:22:04 +0000 Message-ID: <1aed24f9-c2e2-5ffd-cb08-4ce7b7a8588a@intel.com> Date: Tue, 26 Oct 2021 11:21:57 +0100 Content-Language: en-US To: "lihuisong (C)" , Kevin Traynor , "Min Hu (Connor)" , "dev@dpdk.org" CC: References: <20210922033630.41130-1-humin29@huawei.com> <20211011092811.55172-1-humin29@huawei.com> <8decd3d4-4370-2f89-44d5-3e0dd848a628@intel.com> <31cd92b1-d388-bd50-963a-8a85a924c0a2@redhat.com> <82e8ba2a-d9bb-5f73-d878-c9cf0801acef@intel.com> <792354b1-bd2d-3946-72c8-2ab4fc8d07bf@huawei.com> From: Ferruh Yigit X-User: ferruhy In-Reply-To: <792354b1-bd2d-3946-72c8-2ab4fc8d07bf@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB6PR0501CA0020.eurprd05.prod.outlook.com (2603:10a6:4:8f::30) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB6PR0501CA0020.eurprd05.prod.outlook.com (2603:10a6:4:8f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.13 via Frontend Transport; Tue, 26 Oct 2021 10:22:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1e87ff7d-5513-4c20-c96f-08d9986a746a X-MS-TrafficTypeDiagnostic: PH7PR11MB5914: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xavcJH1kifIhgLxSFdO79bkpmO/CeeJCIWzXoJcrIHOQT0ZiQfjTdPoMEj7N2NKfTUPi18yK8LL2Aqiqig4bSXpTO2L9RS/+qy1NFQ+F+gTGn9aODjL9Zi+nOoFLkrim+OFD/NfuTCYb0g+Leye4TJIWw47Z2Sk+XTrdajpHOM1cgXfpcjuqBO5dIWtNbCFkFMqDfXxAlkb3k+nLauGc2Dw9c8FKzGXy+Il8HYDgVQi58onOtBaXaQ/P5SBRS1aGq1UtoDdoMW3IDBhuQULNi94E95Nk1O5UA4XF0hI3ntEqauDDrtdEjUTaYZ/xsWdjLgyk4ABSc8uQbCkeqMkMTbN9ayIIdLfre+qUdn6oo8qyJ4rMjdWZM/6ADt+qLBQBdY7+REIt25yEMtdflfXiyIAQUuOWS6LlyCLrxLUjEo0nUbXXqVl2n+fE+COgi+4UIFYZOVVHIvm0gVJkWJhUtKNYLmQnJzxD2E+q33poREQDU5jHRgaoZhYOSLkKGtVWVN/WwE18p3HIb9LhhK/HcW9Qa7ugwbppaaD+2uUkZzGTRUJ5ohfLUEJaTv6auOY+y+BJN2wCaq3cpIIb4G9fveSteVHSWTnQaU1bnSMxOFzzNf50kY9AnrAyJRBqWZ+0pE8WBzTzsEfwcoLWN+xH2XEEfKA9N+MQziH0lAxN564EBcfhZAShIezbaSVOxYDiIGctcjQFKKCsaGvBMBO/tQ== 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:(366004)(36756003)(508600001)(31686004)(38100700002)(31696002)(5660300002)(26005)(66476007)(6666004)(8676002)(66556008)(316002)(186003)(16576012)(53546011)(83380400001)(82960400001)(956004)(66946007)(6486002)(86362001)(110136005)(2616005)(2906002)(44832011)(8936002)(4326008)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RXhUMzdsYW9Tem5sd25GLzNGejZCVFZDQ0N5aTZSbWNMSXo1U1JjQklXM1Zw?= =?utf-8?B?a3poaXNUNk1iU2dOQ2Rudy9YZTkwQldFYkxOczhycW5xNjBPdzE0cXl0TTJ2?= =?utf-8?B?T0NCa3VzUittVnovZFczbWVPL3ptMFFmWm52RnRMOVU3dmhuT1Fmcmx3a3BQ?= =?utf-8?B?Nk5yV1NDTlRLZHB2YmVkeStId1MzL3gra0dOallxUTVpbTYyVEw4N3VyTHJ4?= =?utf-8?B?ZE43SkRSSUxJOUpqME5odGJxdVVydFNia0JVVk9JeHJPc0pKaE9oYllnRmRB?= =?utf-8?B?WWkzRmN0eXNxNjM1VEJCWXhQSXhWOVZmTGtZSjZqdFV0bVd1c0pwUHZQYysz?= =?utf-8?B?bzZkeDZ2VDJoMEpHTTZzTk5EdlplK3pFK3RxNnZZM3lRZXFZRk5YUi9jVGls?= =?utf-8?B?MThtMTNZdGFxQ1JlZThMcVRoVjd2QlpLd2o3QmI1enB0eWlCTDlHUTNtRjB0?= =?utf-8?B?QTUzVXRDSDdzdnB0dGVvWTNTbFJPVUlIRHBwb1pVM0F5ZTZaR1hYTlprdWJx?= =?utf-8?B?cndGQ1Z4eE5hb1RKZWZOUkN2cm0wckY5QmxsdUkzWWN3dTI0MkRCcmFPTEtI?= =?utf-8?B?VllBbVJoR2d5U1hSMFIzYjZTZGtwMW9lWWU4Sm1YOEw5VXBmRTMrYXV1aDJ5?= =?utf-8?B?b0pDTmZSUG95S0lBSWI1MitkQ1pBanViaHFQRGptMm5wY2FvL2ZmaXlUUWFN?= =?utf-8?B?aEZ3MmRONGgzSk5wcjFud0xrZDFham1BWSswMDBrOUw4RnIvYTNEc1VJMkh2?= =?utf-8?B?YWJsV2t0aEJQaDR2eDJNc2NpM3VBSDNkRThOanEzcUx6bnBZUzV1a3pRczY1?= =?utf-8?B?TENjQWtxRHNiODZVKzJMVXBqL0lKTlNwaW5MNTA3eGx2QUZjeG42UjYwckRh?= =?utf-8?B?U1duMm1OWEdLV3o1dFFoa1JrYnFDK21MWGxmUFZSMFp6TVNWNWJsS3ZmRm9F?= =?utf-8?B?cW5QTDFScFlpK1Jrcm0yeFpmRHpTNjNzbE9JaFJUMWVGNkpuOFk3VmFuL0p5?= =?utf-8?B?bVBxRVMrY3dEQS9pYjJ2NzdWL2FOQ09Lem1QajY4eFBJTjBMUlNOSno0VFBO?= =?utf-8?B?dzlja0Qya3UzMi8vYUlWUHA4akh2V29lMGZYM1d4VmVmUTNrS3JhS1c4c3E1?= =?utf-8?B?ME5sRXFiM09uQ0dmRGtSaldJdVhEMExCN0RlWnVHcnlQSUtnblg1WXVYOGdU?= =?utf-8?B?YnQycldja1N2TGNXUTcvSkJIclpRVjJUUkJ4NWpZNjBOR3ZwRlFsRnlaQTFC?= =?utf-8?B?eEdnNXRjdXNpM2MyQ1JNaEZsT3ErMFAyTy9CQi8xQTRuWUMzalFRZGMxTTdW?= =?utf-8?B?Z1JrampJQWxiUDYxSGowVEtaQWVSa2NBbGxzSkRrcERoYmFsTVJ5NGU2UCtE?= =?utf-8?B?M1g1TWNjS0FHWEhOMUhlT3Y2d0kwWGFCNWhlaE1DRGEzMXFUYXpOYTMxOE11?= =?utf-8?B?R3FwQUY5M2hRdm5BNHhZNm0yOW4zR0ZLVjFMd0ZNTjRoZzJKVXhWWXovbUpT?= =?utf-8?B?Nm41Q3p0M3hqK2ZDVTN5ZkIzOUNRcGZBVzkya0ZYL0lYenM5MEk4M0tjSlBT?= =?utf-8?B?VkY3b3JGYnFOTTFvU3IrSnFWSXUyeWpoSXBvbHNPWkZvVDYvWnRJTGMzUm93?= =?utf-8?B?OG03c3FVbGN4OFFMR3VSSGFDZlIrNUlOY2E0blNWOWNBejFTVDJ6MGxUUUJZ?= =?utf-8?B?ZzlmV1BjU2RTb2NmOThiVmdyQXE2TlRPckxhN2txSWRNTmxjenJsNUNqZGcv?= =?utf-8?B?cnJRYVZSREo0ZlhFMytVYVM4UEV2R0QyQmVXWDZJOGdGOXdlYkJSYWFqdGRD?= =?utf-8?B?R2JqemhDeTl0N3poMEkrU1U0dTFkQmRyL1d1ZzMwOWFicWFCaWdaSThQMjlx?= =?utf-8?B?ZnR4U0U1d2twU3B3QWg4cFArdldkVTlZZVkzR0RRODBsdkU2L1NvWk84Zm56?= =?utf-8?B?RzFyRzQwUVVUdzNhRFY2czdlWDFROTl1MmFBZzk3SWwraXJLYmpKa1pwc011?= =?utf-8?B?Sk5LYVBpdyt2aEFlVDFSSU9EQmc3R1MvSlQrZWVPYlZMODhRU2tsN05sb3Rl?= =?utf-8?B?a2gvR2dGTVhoSmg2cDR0d25mbXVPeEZRVEVabFJ0QW5INXEyUHJCTFZuenRK?= =?utf-8?B?WXpBNkg0Y3M1MnJhTEdwTThhbXJ1SS9HOFlRT3hCRURySnA1RkxzaEQ4a3JD?= =?utf-8?Q?y7oSuPCVNXcXjgtcQoLXQDc=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 1e87ff7d-5513-4c20-c96f-08d9986a746a X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Oct 2021 10:22:03.9852 (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: 94WOjA6mOiy7v1DE5f8vNRFLXHkmL3N/ysm0aFi3rgIvshKdSLppl0a2eY/NtJbASRyCtUkxS8yD52SsHDGPKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5914 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix one MAC address occupies two index in mac addrs 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 Sender: "dev" On 10/22/2021 3:04 AM, lihuisong (C) wrote: > > 在 2021/10/21 16:30, Ferruh Yigit 写道: >> On 10/21/2021 3:05 AM, lihuisong (C) wrote: >>> >>> 在 2021/10/21 0:32, Ferruh Yigit 写道: >>>> On 10/20/2021 11:15 AM, Kevin Traynor wrote: >>>>> On 20/10/2021 08:41, Ferruh Yigit wrote: >>>>>> On 10/20/2021 7:49 AM, lihuisong (C) wrote: >>>>>>> Hi Ferruh >>>>>>> >>>>>>> 在 2021/10/20 1:45, Ferruh Yigit 写道: >>>>>>>> On 10/11/2021 10:28 AM, Min Hu (Connor) wrote: >>>>>>>>> From: Huisong Li >>>>>>>>> >>>>>>>>> The dev->data->mac_addrs[0] will be changed to a new MAC address when >>>>>>>>> applications modify the default MAC address by >>>>>>>>> rte_eth_dev_default_mac_addr_set() API. However, If the new default >>>>>>>>> MAC address has been added as a non-default MAC address by >>>>>>>>> rte_eth_dev_mac_addr_add() API, the rte_eth_dev_default_mac_addr_set() >>>>>>>>> API doesn't remove it from dev->data->mac_addrs[]. As a result, one MAC >>>>>>>>> address occupies two index capacities in dev->data->mac_addrs[]. >>>>>>>>> >>>>>>>> >>>>>>>> Hi Connor, >>>>>>>> >>>>>>>> I see the problem, but can you please clarify what is the impact to the end user? >>>>>>>> >>>>>>>> If application does as following: >>>>>>>>    rte_eth_dev_mac_addr_add(MAC1); >>>>>>>>    rte_eth_dev_mac_addr_add(MAC2); >>>>>>>>    rte_eth_dev_mac_addr_add(MAC3); >>>>>>>>    rte_eth_dev_default_mac_addr_set(MAC2); >>>>>>>> >>>>>>>> The 'dev->data->mac_addrs[]' will have: "MAC2,MAC2,MAC3" which has 'MAC2' duplicated. >>>>>>>> >>>>>>>> Will this cause any problem for the application to receive the packets >>>>>>>> with 'MAC2' address? >>>>>>>> Or is the only problem one extra space used in 'dev->data->mac_addrs[]' >>>>>>>> without any other impact to the application? >>>>>>> I think it's just a waste of space. >>>>>> >>>>>> True, it is a waste. But if there is no other visible user impact, we can >>>>>> handle the issue with lower priority and clarifying the impact in commit log >>>>>> helps to others. >>>>>> >>>>>>>> >>>>>>>>> This patch adds the logic of removing MAC addresses for this scenario. >>>>>>>>> >>>>>>>>> Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier") >>>>>>>>> Cc: stable@dpdk.org >>>>>>>>> >>>>>>>>> Signed-off-by: Huisong Li >>>>>>>>> Signed-off-by: Min Hu (Connor) >>>>>>>>> --- >>>>>>>>> v2: >>>>>>>>> * fixed commit log. >>>>>>>>> --- >>>>>>>>>    lib/ethdev/rte_ethdev.c | 15 +++++++++++++++ >>>>>>>>>    1 file changed, 15 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >>>>>>>>> index 028907bc4b..7faff17d9a 100644 >>>>>>>>> --- a/lib/ethdev/rte_ethdev.c >>>>>>>>> +++ b/lib/ethdev/rte_ethdev.c >>>>>>>>> @@ -4340,6 +4340,7 @@ int >>>>>>>>>    rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr) >>>>>>>>>    { >>>>>>>>>        struct rte_eth_dev *dev; >>>>>>>>> +    int index; >>>>>>>>>        int ret; >>>>>>>>>          RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >>>>>>>>> @@ -4361,6 +4362,20 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr) >>>>>>>>>        if (ret < 0) >>>>>>>>>            return ret; >>>>>>>>>    +    /* >>>>>>>>> +     * If the address has been added as a non-default MAC address by >>>>>>>>> +     * rte_eth_dev_mac_addr_add API, it should be removed from >>>>>>>>> +     * dev->data->mac_addrs[]. >>>>>>>>> +     */ >>>>>>>>> +    index = eth_dev_get_mac_addr_index(port_id, addr); >>>>>>>>> +    if (index > 0) { >>>>>>>>> +        /* remove address in NIC data structure */ >>>>>>>>> +        rte_ether_addr_copy(&null_mac_addr, >>>>>>>>> + &dev->data->mac_addrs[index]); >>>>>>>>> +        /* reset pool bitmap */ >>>>>>>>> +        dev->data->mac_pool_sel[index] = 0; >>>>>>>>> +    } >>>>>>>>> + >>>>>>>> >>>>>>>> Here only 'dev->data->mac_addrs[]' array is updated and it assumes >>>>>>>> driver removes similar duplication itself, but I am not sure if this is >>>>>>>> valid for all drivers. >>>>>>>> >>>>>>>> If driver is not removing the duplicate in the HW configuration, the driver >>>>>>>> config and 'dev->data->mac_addrs[]' will diverge, which is not good. >>>>>>> The same MAC address does not occupy two HW entries, which is also a >>>>>>> waste for HW. After all, HW entry resources are also limited. >>>>>>> The PMD should also take this into account. >>>>>>> So, I think, we don't have to think about it here. >>>>>> >>>>>> I am not sure all PMD take this into account, I briefly checked the ixgbe >>>>>> code and I am not sure if it handles this. >>>>>> >>>>>> Also it is possible to think that this responsibility is pushed to the >>>>>> application, like application should remove a MAC address before setting >>>>>> it as default MAC... >>>>>> >>>>> >>>>> Yes, the API view is more important than saving one entry in an array. From API perspective with this patch, >>>>> >>>>> set_default(MAC1) >>>>> add(MAC2) >>>>> add(MAC3) >>>>> add(MAC4) >>>>> default=MAC1, Filters=MAC2, MAC3, MAC4 >>>>> >>>>> set_default(MAC2) >>>>> default=MAC2, Filters= MAC3, MAC4 >>>>> >>>>> set_default(MAC3) >>>>> default=MAC3, Filters= MAC4 >>>>> >>>>> set_default(MAC4) >>>>> default=MAC4, Filters= >>>>> >>>>> set_default(MAC5) >>>>> default=MAC5, Filters= >>>>> >>>>> Did I get it right? If so, it seems wrong to silently remove the filters. In which case, it would be easier to just not remove them in the first place (current behaviour). >>>>> >>>> >>>> Yep, this is the updated behavior. And agree it looks wrong when you >>>> show like this. (btw, this is only ethdev record of MAC filters, what >>>> is updated in this patch, HW still may be keeping all filters.) >>> >>> Whether HW saves all filters depends on the implementation of the set_default() >>> >>> in the driver. According to the implementation of this API of all PMDs, some drivers >>> >>> will first remove the old default MAC in HW and then add the new one when calling >>> >>> the set_default(). I am not sure if the HW that didn't do this would remove the old >>> >>> default MAC. If not, we may need to standardize this API in the ethdev layer. >>> >>>> >>>>> If they really need to be removed from the filter list when they are set_default(), then perhaps they should be restored to it when there is a new set_default(). >>>>> >>>> >>>> I am for keeping current behavior. Application always can explicitly remove a >>>> MAC filter before setting it default if required. >>> >>> But application can not remove the duplicate MAC if the MAC is the current default >>> >>> MAC by rte_eth_dev_mac_addr_remove(). In this case, it will failed to remove. >>> >> >> But can do other-way around, first remove (the non default one), later >> 'rte_eth_dev_default_mac_addr_set()'. > > This introduces a usage dependency on the user. We don't have a statement in some place > > for the dependency. What's more, if the user does not follow this dependency, the user > > will no longer be able to remove the MAC. > > So it may be more appropriate to deal with problem in ethdev layer. > > > **Scheme A:** > > The decision is left to the user, but there are usage dependency and irremovable possibility.** > ** > > *Scheme B:* > > index = eth_dev_get_mac_addr_index(port_id, addr); > if (index > 0) { >     mac_pool_sel_bk = dev->data->mac_pool_sel[index]; >     rte_eth_dev_mac_addr_remove(port_id, addr); > } > ret = (*dev->dev_ops->mac_addr_set)(dev, addr); > if (ret < 0) { >     if (index > 0) { >         rte_eth_dev_mac_addr_add(port_id, addr, 0); >         dev->data->mac_pool_sel[index] = mac_pool_sel_bk; >     } > >     return ret; > } > > * Scheme C:* > >  Use the method in this patch. It assumes that the driver has only one HW entry for a MAC. > > What do you think we should do? > If the impact is only loosing one entry in the array without any functional effect, I am OK to keep behavior as it is. If there is more motivation for fix, I would prefer option B to be sure all drivers behave same by explicit remove.