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 DB63141D46; Thu, 23 Feb 2023 05:32:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B8C1142FC6; Thu, 23 Feb 2023 05:32:35 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2077.outbound.protection.outlook.com [40.107.7.77]) by mails.dpdk.org (Postfix) with ESMTP id D289540DF6; Thu, 23 Feb 2023 05:32:34 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O4mIMBmPg4QHrml+WDNiDGBY8a//QQkyZBBzUF/L2j+AAg6AFTuprfu9IK2Z+qdBl0gkG3KabbI560DktUEluQgaUeIE+BXYCpJE24bzMYvoV2O6JxHw6Z4vAS4mDOgKamTmoPA63ua5B+V/oCW6zCpufTsscBu+sKbmerU7VODtLOlaW0smWWbvScfV8i1XrBDtoYeLf3nl09WMa5IGLzHMRMcVvxBwtRo5nQV/XqaytiZpyhxnihi1JzDJ17HF2bjb5NGncsTV45P/muJgTdHsww5pO0ycMtFzaUbKiJoKYuFmUMwxei7SpzZMKIaVN0g/7a7XDfDtCxZ5rEaQeQ== 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=jvu1mp8NKbrYdwBpeXMhAKmhXDmu0Ivl7B0XlaxOCLk=; b=hV0GqlO3C6PGRqeJ9Re0k0FgoRuFscbmM1C/j2CxF0GSXk+LRMLuHJWQo8MLo71m+8wJvM3uzS7ltMSd0M/teWarkGee5jPQSiLvAOq8gCya7bvKBKn4jnCIHXnXRaZGiowXk+aqO2eoSfeW+ACGJOdQ2NwKQyYmfrg7Nn5SuxZ8D+talnDQK1I+zELUmS/ks+H4OmJ+9DBZws1Uur3HZ6vFcrx/ZT/wJrp6LCB1ZDH7yCTeRnV+ZxjeJa4Fnr77jZbSvugKZmnEmOdXMySDZ6soJpjH6VUMyfYlLgNUj80QAlT1TFExVxLnNlf6bUHdWwYiCt9XyxZcJOXhzaGF5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com; dkim=pass header.d=oss.nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NXP1.onmicrosoft.com; s=selector2-NXP1-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jvu1mp8NKbrYdwBpeXMhAKmhXDmu0Ivl7B0XlaxOCLk=; b=UHm8gpz8B/QNPe2zPkCEKSPx93HPCHxtlpXLnXXoEroPUqwLXpUD2fXhYuhK8SDZUNy0Nf6wuCzcS3uFTZWAQbFKkT4vl6N1RMHZFfJDTuLWfEo9acLXd7uewIx2ychLBMoZgxJACS5kkv6IxpJF6FlGXjU/xXIC0+eWTIRIUr8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=oss.nxp.com; Received: from AS8PR04MB9064.eurprd04.prod.outlook.com (2603:10a6:20b:447::17) by AS8PR04MB8865.eurprd04.prod.outlook.com (2603:10a6:20b:42c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.19; Thu, 23 Feb 2023 04:32:32 +0000 Received: from AS8PR04MB9064.eurprd04.prod.outlook.com ([fe80::5430:ce3c:47b4:55cf]) by AS8PR04MB9064.eurprd04.prod.outlook.com ([fe80::5430:ce3c:47b4:55cf%8]) with mapi id 15.20.6134.021; Thu, 23 Feb 2023 04:32:31 +0000 Content-Type: multipart/alternative; boundary="------------mPNS2Zo2XNvezokr98JE8TFv" Message-ID: <26318485-9bb5-3dbe-ed76-8fdb3928861b@oss.nxp.com> Date: Thu, 23 Feb 2023 10:02:24 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: MAC address set requires decision To: Honnappa Nagarahalli , "Richardson, Bruce" , Ferruh Yigit , "techboard@dpdk.org" , "dev@dpdk.org" Cc: Huisong Li , Chengwen Feng , nd References: Content-Language: en-US From: Hemant Agrawal In-Reply-To: X-ClientProxiedBy: PN2PR01CA0232.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c01:eb::10) To AS8PR04MB9064.eurprd04.prod.outlook.com (2603:10a6:20b:447::17) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8PR04MB9064:EE_|AS8PR04MB8865:EE_ X-MS-Office365-Filtering-Correlation-Id: a6602648-c8d9-4a3a-e502-08db1556fa59 X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HLR14n6u6lzMxH6hESH9Q1ob7olxiRHpKxwHaeaPabKUG+EK4S9hgudvwKrI9hBq/0R5NCDv0bmTMyPrJ4Z2X173gX+MZ5ZrK+wOtiBxoOuGhc+/rL/TU52e18rPTt9OBkLpqytNpiLEY/N5H15+YX6iYo7RKZaH1irCh885BARMMlr5Niyz/6nYvE1N0KvS7S//A+TyP4RPHXURgJtLyV+02+yvyXI+ppj9I0D6xFhUgCXVCiQitqkymbWQsrKGPP8w0UWpTz92o+IHm6Aq9A3gB67/boVq7zXUnxi2akO4NqloeIF2bmQ65qziOtI8CcxdTSHPsDNMDTphy8k8NPX8AgiTG39mdEaurcV8FbCSChf1lt2QrIi04ri82CU6lqZC6VoVDnZ5tp+4S1YKNkggJU4kD8AD6wOEqN7NWCQEgiqCHjpK+7MgWOJ0EsXgKoLWQh/aN3+060sEy+iWaemVeFmsh7DlJpF7K8QFQQmgu0YcpcMnEWtErj+XTM62/sxIX74o9GMrYkPHHtXBnQb4/DCno+WhczeDVHQff7mDATJnGEvYekH9d8EJOWUkO6+5/pvP96Dq42KSLisF02dG3yaC420M3LD5SyWKz3kozAKjLVScgGANyDTEMvcKkZf61Q5JJfU9WYpzdpB9uXLkLPTXAQzkvGk6oirA0Y3TCjM7bh9sEw1ouHRB2A99JevTFsqCLDqP4Na2pJsM7/JxuQRhKZKq+SeekEEsQ9A= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR04MB9064.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(451199018)(86362001)(31696002)(4326008)(6512007)(41300700001)(2616005)(186003)(53546011)(8676002)(66556008)(6506007)(66476007)(8936002)(26005)(33964004)(66946007)(6666004)(54906003)(6486002)(30864003)(316002)(966005)(110136005)(478600001)(38100700002)(2906002)(166002)(83380400001)(5660300002)(44832011)(31686004)(43740500002)(45980500001)(579004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SmVxelpFNTNuK25zTkN5YTM1bGIvZmtIbVh6amc4NGZKSDNxU3V3ZkRYUjhv?= =?utf-8?B?R1RwdmFET09BbWpNbmRscGFzTmJTTmwvZmhybWhubGpsZzF1N2tneWo5S0Rn?= =?utf-8?B?QTBmbGxRdEhZWFpjMnVzMStXR2J6M0d3VnpUWkVpcVpXeTRnKzJKZmwrNXdN?= =?utf-8?B?cWhSQjJvZDNockhLMjlrVzBwWU0wdmNTaVZXRjNDeFo5cm1xUHY2QWFsUE1D?= =?utf-8?B?aUZESi9yVDJtRW11SFNPbW1UcTVjOGNQUEsxWkd2VkE1RklYVUNmWGtpU2Yz?= =?utf-8?B?bHMvZHYyK2FjSFA1ZHFMaFhJalZXaTlycGp0OUNaYS8rOGZjNHd2QzNjZ2lK?= =?utf-8?B?S2MyejRna1FnZVdEblZtRFE4STc4N3ZxVDlYNFptV1VRS1lvckRXVUVNU0Vp?= =?utf-8?B?K3JCTVZrOVFiT1VGQ3Q4Z1N0Z2JJRzVuV0hTd1JmMmlOcjNIeDdyd0xmdE5E?= =?utf-8?B?SjkyWTk1aHJ5VUhtc1h4cEU1ajIrZUxER1lvaTJWSHRoSGExb1dsMHFqL0Ur?= =?utf-8?B?R1BjdDlwYi9zKzhUeHF5ckMxL1BMQlVtc2hxR2pvZ2g2TXF1ZGFKVk9zWmwy?= =?utf-8?B?bGc1Z2lBUzVDNkNqVktUeTRmcCtEZ0JIN1Jza0t6M21INmVjT2JtOUNWUXlJ?= =?utf-8?B?U3dpTERlUTJKeStaV0QzNVA0Y0M2a295eXRxNjNOcnlTa2JRclVDVUl5a1hj?= =?utf-8?B?cmlwTUFaOFZoTlNrZVQzTHdMdHp3R1A4QzVBU2EwRGZNNUFlbFlsRCtXVFB0?= =?utf-8?B?Qkd4YW1RYVNDb09WamVobHhJSGUxSjRSbGJkMmZtKzBoREp2TXlraHA2c2pY?= =?utf-8?B?UkpRRjhnQ0dnZVdGRTMyYmlyZGRUWGpqYU9oTVM4ZTI2OTRUWWJJQjYzR2xY?= =?utf-8?B?VVdKMitKalVpTVpSMmJ5Mk5FaXhsUUwwTWJ1dlltMmZoRUxQaW5nRGt2dkh6?= =?utf-8?B?K1hlc3hiUmtEdHY1U290TG1QeFVSVlRId1RvUDNZVGVZVzhybmhJVS9hR0o4?= =?utf-8?B?bG9PVHJOSkJIdjF6RXJQUnZFUTJPU3JFVjQ1ekpsbEdFMkN3UGs3SmM0VkdY?= =?utf-8?B?UG5JaEl0M3h1eEZMcDJXNXp5SEVoY1krZ0xuZXpmRHRxM01qUVRsa0NrWmVF?= =?utf-8?B?L2djaFNZb05rQ2VtRXJRL1ZNd1Z4VWlRNUswSHNWdVNyLzdPMDA4dlFQZ0xS?= =?utf-8?B?WEFEYmVEUngxRFR5K05vVHcrL3N0K3Y1bkdXSDhnWlF2bC82MVBuSVo3Q0c3?= =?utf-8?B?VlgzRmpqanRtUk1lTjZzcEhwVUNQaWtNMGpDVG0rWStGTXB2R3pCemJsampp?= =?utf-8?B?cm1kc1ZCcGFkdlhEYjM4MW1yekx3dzNwNTJieHlDdmRnd3ZOT0RPNURlenVQ?= =?utf-8?B?MUdHSXZOMUlKaVExUThsODZ1QUg0RmtCb2NFZEx0U1JUZjBCVll3d1B1c2pC?= =?utf-8?B?VUt5S0JoWXVxRTRlY1ZDM1lwOVBUeW92eVdkUzRxc2U3dW5ENTdCcDRlZWdi?= =?utf-8?B?dkxxRnZuVWZjSkp0UFBnTTNmVERsVTZlbkVMY2p2Qk0ycXU4SVRxeUlsZ2tK?= =?utf-8?B?U0VRUHZJSllaNjEyUUlnaTQvcU5pekttcWJ4UnpXM2lKVExSaTVmTjQ5ZUk2?= =?utf-8?B?UXR4b3d3QzNLWXdtSDlKOVNGQUpuZUVDbVZOaEMrSk1qRjg3cHZzZENmb3Y1?= =?utf-8?B?dXpHYWlrRVJ1NE1Da2R1eURxTUhCd0JSUHhFcWh4RE4wc3FnR0RjWHJJRS85?= =?utf-8?B?M0tTRGw5dG1kNHBObU5BZ2NFdmREZFdhY3poRk0xMnFsTW9uQ2UvcDd6VHlU?= =?utf-8?B?dUlPSkZXZzFXdWc0L2x1MFVXZ0hXaGI1U2s2U216bStKWUVWK3JtMkVOOG9N?= =?utf-8?B?bUtlclhrbWFVcDByT2NNaHFGL1FMcU1QMzJtdHl0aWFUUm41cyt6QzNmTFda?= =?utf-8?B?cDdpd1N5d0xwdWtxbFZ5cjFMeDV6bDNqc0Zvd1UyNW9qTmYzS3FHV29vcktt?= =?utf-8?B?dnBjQmd2V3JVaFgxWkFrbWpPOHlrQjlCNTdvQ0l0V2RSTCt6NnlUeGZQdTBj?= =?utf-8?B?elhOdHdhRjhieUxRYmZEekhaNit3WFNVd20zbnFkY1A1U1FNZmZCMTViU0lD?= =?utf-8?B?dXMrd0dENEg5MWdjNnMwK3ZOdHMvVUd3dWdPUFBDekYxNEdwWHh1OXV6V3B4?= =?utf-8?B?V1E9PQ==?= X-OriginatorOrg: oss.nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6602648-c8d9-4a3a-e502-08db1556fa59 X-MS-Exchange-CrossTenant-AuthSource: AS8PR04MB9064.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 04:32:31.7591 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: eM+z0I0VeWD85QDEzL5ELlkzzSVZaiMYobxk3ZKkJI4xw4lpaj69PI9GOW2QD24/ypP82GFXgW7KfFESZg5H9A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB8865 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: , Reply-To: hemant.agrawal@nxp.com Errors-To: dev-bounces@dpdk.org --------------mPNS2Zo2XNvezokr98JE8TFv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 22-Feb-23 11:25 PM, Honnappa Nagarahalli wrote: > -----Original Message----- >> From: Richardson, Bruce >> Sent: Thursday, February 16, 2023 9:05 AM >> To: Ferruh Yigit;techboard@dpdk.org >> Cc: Huisong Li; Chengwen Feng >> >> 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 Both of the above option seems good.The option #1 above is safe, where you are making the mac address set as independent of mac filtering. Also making sure that mac filter are not messed up. However, the application needs to add error handling now to delete and set. In the option #2,Iassume, it will provide full backward compatibility i.e. the ethernet library can take care of the logic and application need not to implement anything extra ? If that is the case, it seems to be best. Regards Hemant >>> -----Original Message----- >>> From: Ferruh Yigit >>> Sent: Thursday, February 16, 2023 2:44 PM >>> To:techboard@dpdk.org >>> Cc: Huisong Li; Chengwen Feng >>> >>> 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 --------------mPNS2Zo2XNvezokr98JE8TFv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 22-Feb-23 11:25 PM, Honnappa Nagarahalli wrote:
-----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

Both of the above option seems good.  The option #1 above is safe, where you are making the mac address set as independent of mac filtering. Also making sure that mac filter are not messed up. However, the application needs to add error handling now to delete and set.

In the option #2,  I  assume, it will provide full backward compatibility i.e. the ethernet library can take care of the logic and application need not to implement anything extra ? If that is the case, it seems to be best.

 

Regards

Hemant  



        

          
-----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


        

      

    

  


--------------mPNS2Zo2XNvezokr98JE8TFv--