From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
Ferruh Yigit <ferruh.yigit@amd.com>,
"techboard@dpdk.org" <techboard@dpdk.org>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Huisong Li <lihuisong@huawei.com>,
Chengwen Feng <fengchengwen@huawei.com>, nd <nd@arm.com>,
nd <nd@arm.com>
Subject: RE: MAC address set requires decision
Date: Wed, 22 Feb 2023 17:55:08 +0000 [thread overview]
Message-ID: <DBAPR08MB5814F537868A9E6F204F39B798AA9@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <DS0PR11MB73094A6B57F581EA716E3DCD97A09@DS0PR11MB7309.namprd11.prod.outlook.com>
Hello,
Moving this discussion to the dev mailing list as per the request in Techboard meeting today. I could not find a single email with all the responses from Techboard members. So, some of the comments need to be repeated. But this is the base response.
Thanks,
Honnappa
> -----Original Message-----
> From: Richardson, Bruce <bruce.richardson@intel.com>
> Sent: Thursday, February 16, 2023 9:05 AM
> To: Ferruh Yigit <ferruh.yigit@amd.com>; techboard@dpdk.org
> Cc: Huisong Li <lihuisong@huawei.com>; Chengwen Feng
> <fengchengwen@huawei.com>
> Subject: RE: MAC address set requires decision
>
> Alternative suggestions:
>
> 1. Don't allow "set" of mac address to value already in the list. The user must
> delete the entry manually first before adding it. Similarly, "add" fails if no
> default mac address is set. This ensures consistency by enforcing strict
> separation between the default mac address and the extra mac addresses.
> You can't have extra addresses without a default, and you can't have
> duplicates.
>
> 2. Always enforce overlap between the two lists - once default mac address is
> set (automatically adding it to the mac addresses list), you can only replace
> the default mac address by using an already-added one to the list. In this
> case, the default address is only really an index into the address list, and no
> deletion ever occurs.
>
> All the solutions below seem rather mixed to me, I'd rather see either strict
> overlap, or strict non-overlap. Both these cases make it that you need more
> calls to do certain tasks, e.g. with #2 to just replace mac address, you need to
> add, set, then delete, but we can always add new, clearly named APIs, to do
> these compound ops. On the plus side, with #2 we could make things doubly
> clear by changing the parameter type of "set" to be an index, rather than
> explicit mac, to make it clear what is happening, that you are choosing a
> default mac from a list of pre-configured options.
>
> Regards,
> /Bruce
>
> > -----Original Message-----
> > From: Ferruh Yigit <ferruh.yigit@amd.com>
> > Sent: Thursday, February 16, 2023 2:44 PM
> > To: techboard@dpdk.org
> > Cc: Huisong Li <lihuisong@huawei.com>; Chengwen Feng
> > <fengchengwen@huawei.com>
> > Subject: MAC address set requires decision
> >
> > Hi Board,
> >
> > We need a decision on how MAC address set works in DPDK, is it
> > possible to vote offline so we can proceed with the patch for this release?
> >
> >
> > Can you please select one of:
> > a) Keep current implementation
> > b) Proposal 1
> > c) Proposal 2
> >
> > Details below, @Huisong feel free to add/correct if needed.
> >
> >
> >
> > Background:
> > DPDK supports multiple MAC address for MAC filtering. MAC addresses
> > are kept in a list, and index 0 is default MAC address.
> >
> > `rte_eth_dev_default_mac_addr_set()` -> sets default MAC [ set() ]
> > `rte_eth_dev_mac_addr_add()` -> adds MAC to list, if no default MAC
> > set this adds to index 0 [ add() ] `rte_eth_dev_mac_addr_remove()` ->
> > remove MAC from list [ del() ]
> >
> >
> > Problem:
> > When a MAC address is already in the list, if set() called, what will
> > be the behavior? Like:
> >
> > add(MAC1) => MAC1
> > add(MAC2) => MAC1, MAC2
> > add(MAC3) => MAC1, MAC2, MAC3
> > set(MAC2) => ???
> >
> >
> >
> > Current code behavior:
> > add(MAC1) => MAC1
> > add(MAC2) => MAC1, MAC2
> > add(MAC3) => MAC1, MAC2, MAC3
> > set(MAC2) => MAC2, MAC2, MAC3
> >
> > Problem with current behavior:
> > - A MAC address is duplicated in list (MAC2), and this leads different
> > implementation for different PMDs. Some removes MAC2 filter some not.
> > - Can't delete duplicate, because del() tries to delete first MAC it
> > finds and since it first finds default MAC address, fails to delete.
> > (We can fix del() if desicion to keep this implementation.)
> >
> >
> >
> > Proposal 1 (in the patchwork):
> > https://patches.dpdk.org/project/dpdk/patch/20230202123625.14975-1-
> > lihuisong@huawei.com/
> >
> > set(MAC) deletes MAC if it is in the list:
> >
> > add(MAC1) => MAC1
> > add(MAC2) => MAC1, MAC2
> > add(MAC3) => MAC1, MAC2, MAC3
> > set(MAC2) => MAC2, MAC3
> > set(MAC3) => MAC3
> >
> >
> > Disagreement on this proposal:
> > - It causes implicit delete of MAC addresses in the list, so MAC list
> > may shrink with multiple set() calls, this may be confusing
> >
> >
> >
> > Proposal 2 (suggested alternative):
> > set(MAC) {
> > if only_default_mac_exist
> > replace_default_mac
> >
> > if MAC exists in list
> > swap MAC and list[0]
> > else
> > replace_default_mac
> > }
> >
> > Intention here is to prevent implicit delete, swap is just a way to
> > keep MAC address in the list, like:
> > add(MAC1) => MAC1
> > add(MAC2) => MAC1, MAC2
> > add(MAC3) => MAC1, MAC2, MAC3
> > set(MAC2) => MAC2, MAC1, MAC3
> > set(MAC3) => MAC3, MAC1, MAC2
> >
> > Disagreement on this proposal:
> > - It is not clear user expects to keep swapped MAC address.
> >
> >
> > Thanks,
> > Ferruh
next parent reply other threads:[~2023-02-22 17:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <d58e359c-dc25-4c6e-b9a9-436bd9ed08af@amd.com>
[not found] ` <DS0PR11MB73094A6B57F581EA716E3DCD97A09@DS0PR11MB7309.namprd11.prod.outlook.com>
2023-02-22 17:55 ` Honnappa Nagarahalli [this message]
2023-02-23 4:32 ` Hemant Agrawal
2023-02-23 14:18 ` Ferruh Yigit
2023-02-23 14:32 ` Bruce Richardson
2023-03-06 7:01 ` lihuisong (C)
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=DBAPR08MB5814F537868A9E6F204F39B798AA9@DBAPR08MB5814.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=lihuisong@huawei.com \
--cc=nd@arm.com \
--cc=techboard@dpdk.org \
/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).