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 2F7CA41C51; Thu, 9 Feb 2023 13:47:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1B5B54113D; Thu, 9 Feb 2023 13:47:05 +0100 (CET) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2084.outbound.protection.outlook.com [40.107.220.84]) by mails.dpdk.org (Postfix) with ESMTP id DAA814067B for ; Thu, 9 Feb 2023 13:47:03 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUrAoxBbNaXbfUpahPLKHvK9VYDk6GrplFN2kkwe4s2q/VXbWMQS+R2mLmv5lNLxIoLA/dE6Vn8SumaU0Qdg61Kxf0tog1mtwK/GZ+GShHRJsdE9+iB1ECHLtSNi7dXtFgE4+lvavYIgW67mpiVJJyjeKLuF+odY7z2UrGRKOFAYy4xIVZlx5o7Fq/0AM6wDAN7TC8cElFwPvhDRniQE5EtfJk0XjyBvR+i6QRwTRSEYDOg4jeJC1mTPMDhc32L9iurA55wuCyfqStNi55b0YtqzO4sWxtV8RsJT0MSXIaS9Nr+MeA508rP4KxNaOsNxmzMBnTCAcAnlrrQ9Uebpjg== 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=txuLGiboq8JtfKNU/TC7Kgh0yWTiOdkRCl6Kcznh3JU=; b=jOxMecy+8/cA22iVbAUCxM56aFgvYiLNA+vselhd3Q3YAwuWldOvumVda815Asb3gl+lldRsDilkq6kjTgNeXjl4noPoG9rUdoac1/J9oVFJbUHRGyTjRe7mgLBRKeIsfWHzoixtLDhd/WUMfdEwZSsw6GAaXkFM4tEnXH6YTLXcLp3TFa1uiwowHtv+4p/2KrnXvoPCKg8Cs/ka9exxpCRf/napdApzVx7FXnG2V3Jro0f/IJEGdEq6j3Zn+O9gQo454oS0zlvZz2k/wtUjdYlCjuzTQP0csA63P+6GVZMiHe+MmVdRyEZgWAEGIxlpRAL0xslRy9n9kdNR6gY2pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=txuLGiboq8JtfKNU/TC7Kgh0yWTiOdkRCl6Kcznh3JU=; b=s7Bblyg2vo8ibVk9lnkoGCWrOWwpHqu7qjkQO9o24lXdcD35lkTBZ+KjEuhKIHzOfIHJw9iT8TRyVS6OGeRLBnWviJMacSMEj5e41ImZPCNznYY4utIxZjWOqhePqjiP3OBThUu2E+DF1yg4iTYYu8zl12bsXa2RYGPCtHdfcR0= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by CY5PR12MB6129.namprd12.prod.outlook.com (2603:10b6:930:27::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.17; Thu, 9 Feb 2023 12:46:57 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3614:22ed:ed5:5b48]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3614:22ed:ed5:5b48%6]) with mapi id 15.20.6086.017; Thu, 9 Feb 2023 12:46:57 +0000 Message-ID: <4ea785a6-359e-3eab-2799-7f2958ab94a8@amd.com> Date: Thu, 9 Feb 2023 12:45:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-US To: "lihuisong (C)" , Thomas Monjalon Cc: dev@dpdk.org, andrew.rybchenko@oktetlabs.ru, liudongdong3@huawei.com, huangdaode@huawei.com, fengchengwen@huawei.com, jerinj@marvell.com, bruce.richardson@intel.com, maxime.coquelin@redhat.com, david.marchand@redhat.com, =?UTF-8?Q?Morten_Br=c3=b8rup?= References: <20221020093102.20679-1-lihuisong@huawei.com> <20230202123625.14975-1-lihuisong@huawei.com> <9b816855-2b5e-4296-d954-aa23cbd97a4c@amd.com> <6754145.G0QQBjFxQf@thomas> <4344ec91-666f-135c-e342-7b99f6b89ed9@huawei.com> <9acbcaaa-c38e-347c-13da-b433a42c8be8@huawei.com> From: Ferruh Yigit Subject: Re: [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs In-Reply-To: <9acbcaaa-c38e-347c-13da-b433a42c8be8@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0228.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:315::16) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|CY5PR12MB6129:EE_ X-MS-Office365-Filtering-Correlation-Id: a5235769-e81f-4628-89cd-08db0a9bba6e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MjDNhBecy0QqGh9fj9e/TP8ovWcjwvFEs10zWEJAOOq9Cw49hf3XDUUzO3pYKEXkvz7K1aPVDg22lXyH5REutcJXM10hK6ZmA/oN4E4AtY1Bz5Se3heUbp/XaIPQrNcyALPiNrESnLqfw8TNOn8dfr/wLRN1IiAfc4T50Cn8XkMer4daun/lWUuC2KfKbBNSHm7ZsGsHsysLUi/dZzHZDtkggcRcbI6MFUiyKaw1Ka2NKsjqoUuwxRBdYmUw3nbc9RiBsV9zmKtq3KrwOOXNWuMi279AxMLfwUBK6osRI5C0ZcPq2QyNzu4fHdoyG1q9VFB2uuEvzxXlHSk40akF//FPASUqBnp9j71vXnD949U7NabWdXDwz/6SD6Uolc8lDfl8Fsw59hJ16WrquP9crVz4VdAcZcRuddZ8DCZ2+/tvLIwOgoonsOBI7hK6zA2dcWHeRHuuvCJz7qGcEacoYyR+FUlq0sQhIlRowcQdWow5li7PztvSDV4OZvtbG6cneKlyUA8GHc47mF4iowdZogaKGIk2K2UFxtIlSIcgtNtRsDVN0kLCSgfAjZBBazZNr8loV8uo5Yl6Ef2+Oh9hopAVFZc8+F5WpzDwfJHup7565ytd3BD9HBDTfT1oz3WHzOwazLLJ8tEN/WVH4nw8Y3glzyjWAsZwiPxLRTFIz7CjKuZxJOa19aI9sTyxHhyPRS7Ym+9A6kEQMqCLNvqcl8N6vPAvj4PNExzfZM3HBs8= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(366004)(376002)(396003)(39860400002)(346002)(451199018)(31686004)(66899018)(83380400001)(2616005)(478600001)(2906002)(316002)(110136005)(6486002)(38100700002)(36756003)(4326008)(66556008)(44832011)(41300700001)(86362001)(6506007)(8676002)(5660300002)(8936002)(31696002)(26005)(7416002)(6512007)(186003)(66946007)(53546011)(6666004)(66476007)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y3BGUEJ5L2NSaTdyVFZEZEtNUWlDVXRWOUFTRGJiSDFCOTJQSjNDR3ZtR212?= =?utf-8?B?VmRYRXdJU3I1UlFjUEdMVklnSWxwWGlyS1VOUXRzNzBCZUFURHFBVnQySDVM?= =?utf-8?B?a1hnNTNoM1NEVmpGSjl4LzR1Q1h0Vis1T2RzVlU1WDFlMTR2Vm12SjczWkor?= =?utf-8?B?VWZtK2hFZ0RHckRNVGw1OTRWWldwY2VSQUxHc2JHQm1qakJUNUZYeEh1aldQ?= =?utf-8?B?c0NRd2NBUlRMaUI0aVR3RHl5TWNSUmhWaHI1SndPd09RNkRVeFRIcUZ6ZEJX?= =?utf-8?B?ajlPcVhsTkx0SVhWeEdvdy90M2ZaQVdUR3RqNGRuaVIyQ2NuRkl3M3pPN2Fa?= =?utf-8?B?RGZoa2ZLOXhCdHVNRnV2N0Z6akhhclgwZGdtcjFkV3lMbUVZUzFpVC95SnVN?= =?utf-8?B?ZEdFN0k0dzlTLyt6QVYzcVZOd3VzcCtXWVBUdkNJSHJsU3Fya0drRlNuQXA3?= =?utf-8?B?Y1NEdVplbU5WS2FXNmMxRTNubC9jaG9lVnQzVlZIcGMxN0Roc1puSGhRa0xm?= =?utf-8?B?K3BXZWtRUU1OTVlkc0UvaXd2cHVYNkhEckRib3NlSzJnbGN0RUM2YmRMSkhK?= =?utf-8?B?TTkxQWIrMjA5bkFwdVN4Rjg3RHk1aXduN0k2OWttMHZZMVo3Qm1CYWhLOHlt?= =?utf-8?B?VEdoL0dHRTQvR2gwMmpDcmpCU3dXeUF4bE1FUVJrNmxCQXpYWnAzdDg1VWkw?= =?utf-8?B?ZVJlajFxcmRhUmNpMWtZdFFXSnR5ODZWaTVzYi82VkNOcmVaeFgzZUhkTlBV?= =?utf-8?B?TzllVkF4WVhZSE1NVGtRT2VHT25tUTFkdTJ6YU1NVFNIQUZ3bUZTbUpnL2NH?= =?utf-8?B?eVMyU2dFWFFaSUltUzlaME83MjBHMk1QU1FIL2t2VXZXUjd2cjNXUElOcGlm?= =?utf-8?B?cXVkVDN1b0RMSGRNMzNnZ2htLzdCRVpvWFVWdW4rMWJabERUWUJxZkZNSi84?= =?utf-8?B?YTFIVC9rbzUrRC8vYXpENVdMditIWEpENGZ1RzZnMitRMmYrL1RBNEhSK01r?= =?utf-8?B?Q0w4MVZnYlNqVE9LZHhqbUltL1BObERpL0Q0YkM4RUxVRFprUEkzNGZ3RUVF?= =?utf-8?B?WDE3MlUwR1QvdGNvNnFFRXRiVlBYVXlFVUFxWEh2Z21DMjJjRndqUEFHL1JJ?= =?utf-8?B?OE1xeG9nRUVoWGlrbk1XNko5RnpvaEdYV21lc2w4WjVkS0p4dzRRSkJTV29j?= =?utf-8?B?dVBuS2NTdmpON091T1hucjA1OWZKQ014bC9TT1loVUFHNEk1NjBrNmZGc2sw?= =?utf-8?B?SU42WDVpZDZNdk1Rb0QvVEQxSzlKcU8wbCtZQmczOW5PN0N0V0N1M21lRkpq?= =?utf-8?B?d1R1UTltM0pLWXBBdzBlaHRqWW5vMWxTKy9BWjJoYU9uWStaeHpSc2lnK0Yx?= =?utf-8?B?ZmgraWo0QlFQSXFOdEZIS1NMbWxOWUtmdm1qSHZUQ1pqUmtzcHZtOEtwWHor?= =?utf-8?B?cjVLSlNCNlNzZVdVUE4wMkt6WThCVlhnbGl6VUZsTDE5THYvZTBMQlA4UXhz?= =?utf-8?B?SHBFUFJQK0VrVS9USENYaFZUU1JvU092eXJxRjlqRVd0WlVLdEQzOFJ0WW9E?= =?utf-8?B?azEzMktHdmIwb3hOQXdTVFErREh0aWY2NDE5SmxpbjNGN2ZENmRmcUZWZE95?= =?utf-8?B?a1Mvd3pBYzc3SXpWeEVxTEpoRDZkcUxQMGNCVU81ajlTTlJuK1lZRGc4S3Y1?= =?utf-8?B?ZktCbjFOWWxaR1R6Slkrb2lnSGppSk9zWUZUSDlUcnpZYmhZVzRnODh4bkR4?= =?utf-8?B?K0Nxdk9lelMyRkwzclBaUHdhMmtVNEdNeXZPVDRGdzAvQzZhSDVPeTBRZzl5?= =?utf-8?B?MmVGVldQcitBVmRLOEtXeWtkRjRmZEkzYnYxSUFNS0dlMUhCR2tscXZrMlZr?= =?utf-8?B?NmgvOXpZM3k0Vk41VDE2QlRqTTJaVTEvQkRCWUNJcEoyTnNQMENJSDhOSHdL?= =?utf-8?B?RFVicWNhZGpMQkFVWDVyT0pIdndUeWUvK0hyY0lNQUNJeENnSE0rUmkwK05r?= =?utf-8?B?NEdydmd0cWtsSzY5M2VnN1U4ZWg4eWZISExucUd4ZldIcHRIanJNZXhYZXE5?= =?utf-8?B?TVFyWEQzRnJ5NU9FM0pOZ0hJa0pwNFpETVU5ZUk1VlUrWUpLeG84anFwZXZs?= =?utf-8?Q?pwp5JpgNP4UpW82+WRs+9tXUO?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5235769-e81f-4628-89cd-08db0a9bba6e X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2023 12:46:56.9237 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: IL60XG3DXEt0GVt774fMh4LYsRD7i0mtfFcUdMObn+BKF9AuVIF3wCTBBO6G8KIo X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6129 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/4/2023 2:57 AM, lihuisong (C) wrote: > > 在 2023/2/3 20:58, Ferruh Yigit 写道: >> On 2/3/2023 1:56 AM, lihuisong (C) wrote: >>> 在 2023/2/3 5:10, Thomas Monjalon 写道: >>>> 02/02/2023 19:09, Ferruh Yigit: >>>>> On 2/2/2023 12:36 PM, Huisong Li wrote: >>>>>> The dev->data->mac_addrs[0] will be changed to a new MAC address when >>>>>> applications modify the default MAC address by .mac_addr_set(). >>>>>> However, >>>>>> if the new default one has been added as a non-default MAC address by >>>>>> .mac_addr_add(), the .mac_addr_set() doesn't remove it from the >>>>>> mac_addrs >>>>>> list. As a result, one MAC address occupies two entries in the list. >>>>>> Like: >>>>>> add(MAC1) >>>>>> add(MAC2) >>>>>> add(MAC3) >>>>>> add(MAC4) >>>>>> set_default(MAC3) >>>>>> default=MAC3, the rest of the list=MAC1, MAC2, MAC3, MAC4 >>>>>> Note: MAC3 occupies two entries. >>>>>> >>>>>> In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove >>>>>> the >>>>>> old default MAC when set default MAC. If user continues to do >>>>>> set_default(MAC5), and the mac_addrs list is default=MAC5, >>>>>> filters=(MAC1, >>>>>> MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the >>>>>> list, >>>>>> but packets with MAC3 aren't actually received by the PMD. >>>>>> >>>>>> So need to ensure that the new default address is removed from the >>>>>> rest of >>>>>> the list if the address was already in the list. >>>>>> >>>>> Same comment from past seems already valid, I am not looking to the >>>>> set >>>>> for a while, sorry if this is already discussed and decided, >>>>> if not, I am referring to the side effect that setting MAC addresses >>>>> cause to remove MAC addresses, think following case: >>>>> >>>>> add(MAC1) -> MAC1 >>>>> add(MAC2) -> MAC1, MAC2 >>>>> add(MAC3) -> MAC1, MAC2, MAC3 >>>>> add(MAC4) -> MAC1, MAC2, MAC3, MAC4 >>>>> set(MAC3) -> MAC3, MAC2, MAC4 >>>>> set(MAC4) -> MAC4, MAC2 >>>>> set(MAC2) -> MAC2 >>>>> >>>>> I am not exactly clear what is the intention with set(), >>>> That's the problem, nobody is clear with the current behavior. >>>> The doc says "Set the default MAC address." and nothing else. >>> Indeed. But we can see the following information. >>>  From the ethdev layer, this set() API always replaces the old default >>> address (index 0) without adding the old one. >>>  From the PMD layer, set() interface of some PMDs, such as i40e, ice, >>> hns3 and so on (as far as I know), >>> also do remove the hardware entry of the old default address. >> If we define behavior clearly, I think we can adapt PMD implementation >> according it, unless there is HW limitation. > Right. I think this is another point (issue 2/) to be discussed. > Namely, whether the old default address should be removed when set new > default one. > If we want to explicitly unify the behavior of all PMDs in ethdev layer > as described above, > there may be no problem if do the following: > 1) In the ethdev layer, remove the old default address if the old one is > exist. > 2) For PMD i40e, ice and hns3, remvoe the code of deleting the old > default address before adding the new one. >    For other PMDs, we probably don't need to do anything because they > have supported remove_addr() API. >    (Without explicitly removing the old default address, I don't know if > their hardware or firmware >     removes the old one when set a new address. But, we explicitly > remove the old one in ethdev layer now, >     I'm not sure if this has an effect on these PMDs.) >>>>> if there is >>>>> single MAC I guess intention is to replace it with new one, but if >>>>> there >>>>> are multiple MACs and one of them are already in the list intention >>>>> may >>>>> be just to change the default MAC. >>>> The assumption in this patch is that "Set" means "Replace", not "Swap". >>>> So this patch takes the approach 1/ Replace and keep Unique. >>>> >>>>> If above assumption is correct, what about following: >>>>> >>>>> set(MAC) { >>>>>       if only_default_mac_exist >>>>>           replace_default_mac >>>>> >>>>>       if MAC exists in list >>>>>      swap MAC and list[0] >>>>>       else >>>>>      replace_default_mac >>>>> } >>>> This approach 2/ is a mix of Swap and Replace. >>>> The old default MAC destiny depends on whether >>>> we have added the new MAC as "secondary" before setting as new default. >>>> >>>>> This swap prevents removing MAC side affect, does it make sense? >>>> Another approach would be 3/ to do an "Always Swap" >>>> even if the new MAC didn't exist before, >>>> you keep the old default MAC as a secondary MAC. >>>> >>>> And the current approach 0/ is to Replace default MAC address >>>> without touching the secondary addresses at all. >>>> >>>> So we have 4 choices. >>>> We could vote, roll a dice, or find a strong argument? >>> According to the implement of set() in ethdev and PMD layer, it always >>> use "Replace", not "Swap". >>> If we use "Swap" now, the behavior of this API will be changed. >>> I'm not sure if the application can accept this change or has other >>> effects. >>> >> This patch is also changing behavior, because of implied remove address, >> same concern is valid with this patch. > Indeed, it changes the behavior. > But this patch only resolves the problem (issue 1/) that the entries of > the MAC address list possibly are not uniques. > Fixing it may be little impact on the application. >> >> >> As I checked again current implementation may have one more problem >> (this from reading code, I did not test this): >> add(MAC1) -> MAC1 >> add(MAC2) -> MAC1, MAC2 >> set(MAC2) -> MAC2, MAC2 >> del(MAC2) -> FAILS >> >> This fails because `rte_eth_dev_mac_addr_remove()` can't remove default >> MAC, and it only tries to remove first address it finds, it can't find >> and remove second 'MAC2'. >> I wasn't too much bothered with wasting one MAC address slot, so wasn't >> sure if a change is required at all, but if above analysis is correct I >> think this is more serious problem to justify the change. > Your analysis is fully correct. >> >> >> I don't think always swap (option /3) is good idea, specially for single >> MAC address exists case, and current case has (option 0/) has mentioned >> problems. > +1 >> Remaining ones are mix of swap and replace (option 2/) and this patch >> (option /1). >> >> I think mix of swap and replace (option 2/ above) has some benefits: >> - It always replaces default MAC >> - Prevents duplication MAC address in the list >> - Doesn't implicitly remove address from list > As far as I know, the first entry (index 0) always be the default > address in all PMDs, > but it's not documented. (So this patch did it, that's what was > discussed earlier). > The 'Swap' may be inappropriate. It may need to be discussed. Yes, index 0 always holds the default MAC, +1 to document this. In option /2, MAC swap is done only if the MAC address is already in the list. Another option can be to store an enabled/disabled flag for each MAC address in the list. In set(MAC), if MAC is already in the list, the existing one in the list can be disabled. Next time default MAC changed, disabled MAC can be enabled again. Like: (d) => disabled add(MAC1) -> MAC1 add(MAC2) -> MAC1, MAC2 add(MAC3) -> MAC1, MAC2, MAC3 add(MAC4) -> MAC1, MAC2, MAC3, MAC4 set(MAC3) -> MAC3, MAC2, MAC3(d), MAC4 set(MAC4) -> MAC4, MAC2, MAC3, MAC4(d) set(MAC2) -> MAC2, MAC2(d), MAC3, MAC4 set(MAC5) -> MAC5, MAC2, MAC3, MAC4 The ones disabled in the ethdev layer can be explicitly removed in drivers, and the ones enabled in the ethdev layer can be explicitly added back in drives. This simplifies the driver implementation a lot. >> >> BUT, if the agreement is this patch (option 1/) I am OK with that too, I >> just want to make sure that it is discussed. >> >> >>> BTW, it seems that the ethernet port in kernel also replaces the old >>> address if we modify the one. >>> Use the test command: ifconfig eth0 hw ether new_mac >> For default MAC address it is more clear that intention is to replace >> it, but question is about what to do with the list of MAC addresses. > Hi Ferruh and Thomas, > > As mentioned above, they are actually two problems (issue /1 and issue /2). > Can we deal with them separately? > #1 For issue /1, it's really a problem. This patch is responsible for it. > #2 For issue /2, I will send a RFC to discuss as described above. >      It may require the participation of all PMD maintainers. > > What do you think? > Agree to separate fixing drivers (issue /2) and ethdev (issue /1), and drivers can be fixed after ethdev clarified. Sorry that this patch is taking time because expected behavior is not clear, and we are not getting enough feedback for it. Also issue is not a major or a blocking issue.