From: "lihuisong (C)" <lihuisong@huawei.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>,
Thomas Monjalon <thomas@monjalon.net>
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,
"Morten Brørup" <mb@smartsharesystems.com>
Subject: Re: [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs
Date: Thu, 9 Feb 2023 16:32:26 +0800 [thread overview]
Message-ID: <246d2d27-d898-48b5-f708-62293dd281da@huawei.com> (raw)
In-Reply-To: <9acbcaaa-c38e-347c-13da-b433a42c8be8@huawei.com>
在 2023/2/4 10:57, lihuisong (C) 写道:
>
> 在 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.
>>
>> 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?
>
>
Hi Ferruh and Thomas,
What do you think of the above proposal?
Looking forward to your reply.
/Huisong
>>
>> .
> .
next prev parent reply other threads:[~2023-02-09 8:32 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 3:36 [dpdk-dev] [PATCH] ethdev: fix one MAC address occupies two index in mac addrs Min Hu (Connor)
2021-09-22 6:39 ` Andrew Rybchenko
2021-09-22 7:43 ` Huisong Li
2021-09-22 8:02 ` Andrew Rybchenko
2021-09-22 9:48 ` Huisong Li
2021-10-05 19:21 ` Thomas Monjalon
2021-10-08 7:02 ` Min Hu (Connor)
2021-10-08 10:04 ` Thomas Monjalon
2021-10-09 9:53 ` Min Hu (Connor)
2021-10-11 9:02 ` Thomas Monjalon
2021-10-11 9:28 ` [dpdk-dev] [PATCH v2] " Min Hu (Connor)
2021-10-11 10:35 ` Thomas Monjalon
2021-10-12 2:58 ` lihuisong (C)
2021-10-12 7:14 ` Thomas Monjalon
2021-10-15 2:00 ` lihuisong (C)
2021-10-19 17:45 ` Ferruh Yigit
2021-10-20 6:49 ` lihuisong (C)
2021-10-20 7:41 ` Ferruh Yigit
2021-10-20 10:15 ` Kevin Traynor
2021-10-20 16:32 ` Ferruh Yigit
2021-10-21 2:05 ` lihuisong (C)
2021-10-21 8:30 ` Ferruh Yigit
2021-10-22 2:04 ` lihuisong (C)
2021-10-26 10:21 ` Ferruh Yigit
2021-11-08 6:55 ` lihuisong (C)
2022-04-25 6:42 ` Min Hu (Connor)
2022-10-20 9:31 ` [PATCH V5] ethdev: fix one address occupies two indexes in MAC addrs Huisong Li
2022-11-16 7:37 ` lihuisong (C)
2022-12-06 8:08 ` lihuisong (C)
2023-01-10 1:00 ` fengchengwen
2023-01-18 8:26 ` Thomas Monjalon
2023-01-18 8:38 ` Thomas Monjalon
2023-01-19 10:09 ` lihuisong (C)
2023-01-19 9:57 ` lihuisong (C)
2023-01-19 14:38 ` Thomas Monjalon
2023-01-28 1:38 ` lihuisong (C)
2023-01-31 6:41 ` [PATCH V6] ethdev: fix one address occupies two entries " Huisong Li
2023-02-01 10:42 ` Thomas Monjalon
2023-02-01 12:26 ` lihuisong (C)
2023-02-01 13:15 ` [PATCH V7] " Huisong Li
2023-02-01 16:37 ` Thomas Monjalon
2023-02-02 1:11 ` lihuisong (C)
2023-02-02 11:50 ` Thomas Monjalon
2023-02-02 12:19 ` lihuisong (C)
2023-02-02 12:36 ` [PATCH V8] " Huisong Li
2023-02-02 13:11 ` Thomas Monjalon
2023-02-02 18:09 ` Ferruh Yigit
2023-02-02 21:10 ` Thomas Monjalon
2023-02-02 21:50 ` Morten Brørup
2023-02-03 1:56 ` lihuisong (C)
2023-02-03 12:58 ` Ferruh Yigit
2023-02-04 2:57 ` lihuisong (C)
2023-02-09 8:32 ` lihuisong (C) [this message]
2023-02-09 12:45 ` Ferruh Yigit
2023-02-10 9:54 ` lihuisong (C)
2023-02-10 12:27 ` Ferruh Yigit
2023-02-10 13:20 ` lihuisong (C)
2023-05-16 11:47 ` lihuisong (C)
2023-05-16 14:13 ` Ferruh Yigit
2023-05-17 7:45 ` lihuisong (C)
2023-05-17 8:53 ` Ferruh Yigit
2023-05-17 11:46 ` lihuisong (C)
2023-05-17 13:43 ` Ferruh Yigit
2023-05-19 3:00 ` [PATCH V9] " Huisong Li
2023-05-19 8:42 ` Ferruh Yigit
2023-05-19 9:21 ` lihuisong (C)
2023-05-19 9:31 ` [PATCH V10] " Huisong Li
2023-05-19 10:45 ` Ferruh Yigit
2022-05-14 2:00 ` [PATCH V3 0/2] ethdev: fix MAC addrs list Min Hu (Connor)
2022-05-14 2:00 ` [PATCH V3 1/2] ethdev: fix one address occupies two indexes in MAC addrs Min Hu (Connor)
2022-05-14 2:00 ` [PATCH V3 2/2] ethdev: document default and non-default MAC address Min Hu (Connor)
2022-05-31 15:22 ` [PATCH V3 0/2] ethdev: fix MAC addrs list Andrew Rybchenko
2022-06-01 6:43 ` Min Hu (Connor)
2022-06-01 6:39 ` [PATCH v4 " Min Hu (Connor)
2022-06-01 6:39 ` [PATCH v4 1/2] ethdev: fix one address occupies two indexes in MAC addrs Min Hu (Connor)
2022-06-01 17:49 ` Andrew Rybchenko
2022-06-02 3:16 ` lihuisong (C)
2022-06-02 13:54 ` Andrew Rybchenko
2022-06-11 9:04 ` lihuisong (C)
2022-06-01 6:39 ` [PATCH v4 2/2] ethdev: document default and non-default MAC address Min Hu (Connor)
2022-06-01 17:49 ` Andrew Rybchenko
2022-06-01 17:49 ` [PATCH v4 0/2] ethdev: fix MAC addrs list Andrew Rybchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=246d2d27-d898-48b5-f708-62293dd281da@huawei.com \
--to=lihuisong@huawei.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=huangdaode@huawei.com \
--cc=jerinj@marvell.com \
--cc=liudongdong3@huawei.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).