DPDK patches and discussions
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: <dev@dpdk.org>, <ferruh.yigit@intel.com>,
	<andrew.rybchenko@oktetlabs.ru>,
	 "Min Hu (Connor)" <humin29@huawei.com>
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix one MAC address occupies two index in mac addrs
Date: Fri, 15 Oct 2021 10:00:25 +0800
Message-ID: <12327092-f335-7c86-ed49-a6716cbf63da@huawei.com> (raw)
In-Reply-To: <2863918.lGjFY7q0R8@thomas>


在 2021/10/12 15:14, Thomas Monjalon 写道:
> 12/10/2021 04:58, lihuisong (C):
>> 在 2021/10/11 18:35, Thomas Monjalon 写道:
>>> 11/10/2021 11:28, Min Hu (Connor):
>>>> From: Huisong Li <lihuisong@huawei.com>
>>>>
>>>> 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[].
>>>>
>>>> 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 <lihuisong@huawei.com>
>>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>>> ---
>>>> +	/*
>>>> +	 * 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[].
>>>> +	 */
>>> This is the definition of mac_addrs:
>>>
>>>       struct rte_ether_addr *mac_addrs;
>>>               /**< Device Ethernet link address.
>>>                *   @see rte_eth_dev_release_port()
>>>                */
>>>
>>> I feel we need to explain there can be multiple addresses,
>>> the first one being the default.
>> Do you mean that the problem mentioned in this patch is not a problem?
> It is not a problem if it is expected,
> but nothing is defined.
>
>> Should we accept this scenario?
> We need to decide what is the correct behaviour.
> I see pros and cons on both sides.
Where's the bright side of this behavior?
>>> Another comment,
>>> If we remove the duplicate, we may have to copy to previous default one
>>> to avoid completely deleting the previous default address.
>> That's not necessary.
>>
>> Because the previous default address has been removed from hardware.
>>
>> After the default MAC address is modified, the previous default one is
>> invalid.
> No you don't get it.
> With the current behaviour, the app could keep all the MAC addresses,
> and copy one as the default while keeping it in the rest of the list.
> You are suggesting a different behaviour where there is no duplicate.

This behavior seems to be contrary to the rte_eth_dev_mac_addr_add() API.

If the pmd does not support the dev_ops->mac_addr_set, the 
rte_eth_dev_mac_addr_add()

is used to set default MAC in ethdev layer. Namely, the 
rte_eth_dev_mac_addr_add() can

be used to set default MAC in the special scenario and add MAC address.

But the API does not allow the rest of the list to be the same as the 
default MAC which

occupies idx 0.


If the app uses the MAC address in dev->data->mac_addrs[] to set the 
default MAC,

the PMD actually has only one entry.  As far as I know, the 
dev->data->mac_addrs[] in

ethdev layer should be consistent with the hardware entry of the PMD.

So I think the behavior referred to in this patch is inappropriate.

>
>>> Not sure what should be the behaviour.
>
>
> .

  reply	other threads:[~2021-10-15  2:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22  3:36 [dpdk-dev] [PATCH] " 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) [this message]
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-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=12327092-f335-7c86-ed49-a6716cbf63da@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=humin29@huawei.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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git