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 7470D41D50; Thu, 23 Feb 2023 15:19:13 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 22CE9431F4; Thu, 23 Feb 2023 15:19:13 +0100 (CET) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2048.outbound.protection.outlook.com [40.107.94.48]) by mails.dpdk.org (Postfix) with ESMTP id 78BF743196; Thu, 23 Feb 2023 15:19:11 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i1F0/lFyMWBFT+lB8zXrLvOnBU0ym7jC/aBIpXwaT5DIvGDpNfRc4nOjF0dkNx/Wbb5hJSrYiaJexqCNU49mRL0le2MCl7H9N6PZH8/vquRqaCSGst9wsa3exnFY7vsbxbZXcQxOeRg0fRfixUzqoCB3KDJvcOyeI0yPjGC8pg/aHWokqm1nDm9tdtaU23HBSp8QSQ1VQEG2A63iXJPkKRA/gOOG7+DP21a5NYG4d5WNejhVrN+o43CDyiTicRGuIBi1u4PT/LZ4CYPo/Pbg9JFJ2CqnfANn3smwlicQfNczu671VWc+T+h65iuzR/hvvn6K9GU1wkTk5cbBvxr96Q== 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=bxizijh9PWivaMatPgz4gbtq4E7FiJXtmWK3DGUkWQA=; b=Z+qHsrDuposwio7ZK3MZXGRcMD53LFqXTn7GGefOM0WmIKajeDn+PeqM1V4dYcZaOIm30qLxbOz7TVcY3qtTkMDFbsbQ8gMvwFJpGg+8k7zQA+MQsRwd2HmKWSZsrsi1zSaBtqsIlxcEIUWTB0BH0TItUbMOU0wYHaxShQ0gKfGZPxeGf7ws6f+WYEaT16JB9qztUWNPr+WSYomJ8Ds7CB7b8RYyQobbPONbflL/us5m8ZOtEdFkskre5wNOmyskySRxk1WocCoK0O0G39iFRwMZczKkqx/eCNTCftRL0biYtdPtFrQrSxQOfM8zuXJ0J8IExtNoVr1DYOA5sg1WIA== 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=bxizijh9PWivaMatPgz4gbtq4E7FiJXtmWK3DGUkWQA=; b=1+CczS9+fnVnVB5qR+iqG2y77TUgNQCQ9H6rh6DDsAhxpRhCbK81bLsQmRfTm/ZV9pL3WOaQN9gp6uCPqHDofePNvhaO1saalBcFnxolwG1uHXYfHPDjFXhlaamA4XngRSNBONCP7JJ896i5nv7Xs5sEHO4hwGFbDLUuepatEGc= 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 IA1PR12MB8238.namprd12.prod.outlook.com (2603:10b6:208:3f9::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 14:19:08 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3614:22ed:ed5:5b48]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::3614:22ed:ed5:5b48%8]) with mapi id 15.20.6134.021; Thu, 23 Feb 2023 14:19:08 +0000 Message-ID: <09b41503-3e69-e787-d10a-fa579333e49b@amd.com> Date: Thu, 23 Feb 2023 14:18:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Content-Language: en-US To: hemant.agrawal@nxp.com, Honnappa Nagarahalli , "Richardson, Bruce" , "techboard@dpdk.org" , "dev@dpdk.org" Cc: Huisong Li , Chengwen Feng , nd References: <26318485-9bb5-3dbe-ed76-8fdb3928861b@oss.nxp.com> From: Ferruh Yigit Subject: Re: MAC address set requires decision In-Reply-To: <26318485-9bb5-3dbe-ed76-8fdb3928861b@oss.nxp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0167.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::35) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|IA1PR12MB8238:EE_ X-MS-Office365-Filtering-Correlation-Id: 0b987ec6-092f-4864-b25d-08db15a8ed6a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 75F1DIelJJgwUMaNy0c/aaGgev73QApu5dD9ME8FpcLFM9VU4SaXofgZQlPEHjSPFE58h9bJxmL7AskVBAmnkuj5Lehw9+7Pk+L3GAjtuCHnnCqRTmXnrh3ges6xGxcACDE7qCS9DXgLPNyOzWTY6x4qXlAjlNktwgFajDUdmIEGW3278HZPYPXT5K3RLuDenF03V2eKwxAPs5i28C3ojH00tsZ/nGkAaWIV1Y/PrB07L7/m6XoTaZsgDCqtR1eVX6S+v8FTR+V5loReUMpwN5vS/4vYNIa5PH1frhkXnDc2LHEAxxaUpM0/m8STnw+9yVs9gbf//SGv4ewRfrMJ+HfdOe6N4UoQZE5jEHtCSGP5w1M5hijsKEE71OJgVvaVZrTW8Zzt1EkIhzJtu6D9ga1yxnb3uaYYpt5as12EQFP74dmxSnu4EJXGP44Fk2U3xa2S73170jXh1ozd0k6X7BoaYYwZL8BY+x6Qu5HMG5Qbx6to/4cHpDBrNSnlyJWdZ/KjzKoPjfuU079T6t45ZuuxUvjAbcw5TEN+q6KuyP1s7j5WjTkXY1IstgIo97pwnec87dgwqPcRCYS+SektgEDSOUbFrQzgL4mD1tjTj+30SNYWvR3D0xDZsvfXamsHBsS2vZR46IcNNkVHvMsDqBYQ5MgWtlg6kjhtbCdOttGi+8vjeVOA9l8Sfyv3cga3sFvAk9SoXb/p2uKtkf9PEE85ZvxNviLzojTpw1YAsJA= 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)(396003)(376002)(366004)(136003)(346002)(39860400002)(451199018)(86362001)(31696002)(36756003)(54906003)(53546011)(316002)(83380400001)(478600001)(110136005)(6506007)(6666004)(31686004)(26005)(186003)(2616005)(966005)(6486002)(6512007)(8936002)(5660300002)(44832011)(66946007)(41300700001)(38100700002)(66556008)(4326008)(8676002)(66476007)(2906002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NXl0TTREQko1c2pQNVpicCtaT2JSdGNNditac01yOVdtR3pXVktnOHd1NEtk?= =?utf-8?B?VmxKeUhsbHp4bzM3VjJwY3JjVUNXelBXQXlEeC9UVSswRG5qSC9jYnhvTVQx?= =?utf-8?B?T1FOMHU5bHVZZHZGQmFQRmlxUU9SSlpNbW1UaVFacTRFVi9vOWU2UFB4bTUr?= =?utf-8?B?VjRQcUlqbkpWUmo1MGZ1WlBQRDJXTmRGTWhGS0F2V1BTeFFXempLUVRKVkxa?= =?utf-8?B?M1ZEMFNCempGUXAxMnp4U21meDNRakN5S1hvK0pROUQ4ck53ekM0MWQwdDNz?= =?utf-8?B?RmRhYkduSTFsSXRDNnBVQ3IyeTRZdk9CVWdXMTZLNFhKR2htRExXa3FMa012?= =?utf-8?B?S20zUDdqbE1TdW1sVjNhWkdwdWQ2ZXVrTUlmNlVmOUZRdi9BVDZ3d2Ywa2Fs?= =?utf-8?B?NlpQQzZ5OVBCNXFBVVFwUkZ0ck5mSWgzWUdQZytKZWpzckpyZVpHejJzQWlV?= =?utf-8?B?WTI2QnVkMzRYbzYyRjZ0Rzl4NUFNZlRmcXZrTXNjSG9Eb3pDcDBGT1V4OFJk?= =?utf-8?B?R3dodk5iazdJU213cmdXdWVsL3pKNE9vWHVwdFdnRFhVekhrTXFBM2VMUG1s?= =?utf-8?B?WHVjQzV1M0U0VklHQ1RzTmdHOWRjQ041VEFPRUUvR2NHVDVVQ0czK2VlWEFY?= =?utf-8?B?di9UMWIrdWhHWmZtcldDM2NKSnk2TlVidGJTL2dSSmtpUURJWHU3U1BQeGVj?= =?utf-8?B?MWFudVR3M0hsVXhQcDlhWmVmZW96VDhlQ2VVMm10RW4wT0dPcG1sS0IrcG9w?= =?utf-8?B?SkhzZktsUWN5bEVzd3ZkTER6UldtQ1BNSG9pTUx1QUFXQ0R2OGdXaytOMFJG?= =?utf-8?B?UWVNL1JWeHJRZUJBbHErb3A0UmV3bmI3bzFlbE4zNUxNM3RhSmw3bkcwNG9K?= =?utf-8?B?Qy9la3puU1g2SEF5cEY4NEpSOFpEbFlvWk9xZVJDTU1LQUJvZC94WERnbmVR?= =?utf-8?B?RENWbHFIK1JWZXh6OFgxOU1CcVVhOHZreGpTcWhMTUw3bzNqREI1enZyRU1N?= =?utf-8?B?YUM5RHpxdkxBYithbmJZWTRPR2t2NDN1V0NDd0thT0xyQVR3Uk92cHhoc3Ns?= =?utf-8?B?bXBtNFpXOGdzVlV6NzVScURzaHhjYTczQUNGZjNHS2dwT2VzZWVib1R2eDNa?= =?utf-8?B?NWVZZ2JJeHkzQmVhY216OG5UZzUvU1RFY3FMZ1JGSkg0M0RQV0wwbnlwWko0?= =?utf-8?B?RzZOdmR0d25HdndjNkYvc0tDcFBzWUdhZXd1TFl3eHJDbFMwWThuOTJ1MWNJ?= =?utf-8?B?VHoxd2FOdkxkeE5Nb1pPdmR6eGpJVFQ4QnlJK3VaZUQ0cDdVY0hRRTExZkdx?= =?utf-8?B?eXFOWWdLZE5kdEJYOU5rZUttWEFrbEF3bFFSYWlOSTdvSDNveEtNUFl1Y0ZU?= =?utf-8?B?K25IYzdUOUtMR3JvVENpelV5b29WL2tleFFxenR4ZEpNTkFmaWVzN1ZtZk82?= =?utf-8?B?V2hScnZlMDBpUE0yTHh3ck9BN01pVmFxL0IvRHovQXQ0QUhJMHY4OUJKdXY0?= =?utf-8?B?S09NUU1DRnA1UkNEcHBNeUk1RUZlUWt2cEVRM0F0U09EMU9RWU4zNzAyWVBM?= =?utf-8?B?RmxvdXRPb3VkYnpsTjE3UG9jV2NXeUozbEdBRStXTWYvTFppS1dPazZPc1Zn?= =?utf-8?B?UkpiaEx1TWQ2NDR3dXhtQkhHeEZqbmo2NFRKMG1aWGJXZ1FzbU1FQkJNb200?= =?utf-8?B?Zy9ocTFwelJJVEdQU2JXMDZaSFdwOTdXbENKanZJcUpxbmxZbXRORkVOVHlW?= =?utf-8?B?NGpnYUxJK3U2MU5JazJtelBUcFBZNGIvd2hTbXFkNVJNT1Z2SzlHd01ZNnBV?= =?utf-8?B?U3A4OCtmSnNXMFZubVRRSGY5cDZ6Z2huM3RKcWk2aW04ckt1amtvenZqaTRn?= =?utf-8?B?Unl6ZFJyQU5HZG5VNmxSWVB6VkFNR3VoWS9mSGs0dytRaTYwWExPUGUvblU4?= =?utf-8?B?clhXR2RXeGRJcFFHTUJKdVVZd3NtYVJMZ2RodzVnejNKL0FsbVdxU0NiRlFN?= =?utf-8?B?UU8vQ3hUZ1pMWGlJMFk2RXdBV1RYcU13bk1SMVdDREVLTFpZWWx1L0w2WXBK?= =?utf-8?B?SXRnUmZKT3YzVmRoSWRQZHhLWWxNSXlFK29RTTdLR2syVUpsR0xXcUQ2UXBx?= =?utf-8?Q?PKcPTKtM8e+N/XZH7ldLxq/s6?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b987ec6-092f-4864-b25d-08db15a8ed6a X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2023 14:19:08.7295 (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: +p4xVKW088wvRwxeChSbgUIIZfKy/WfXCoV4xCrSMSIyjMlxcysp8A1BIehPKllv X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB8238 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/23/2023 4:32 AM, Hemant Agrawal wrote: > > 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,  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. > I think #2 is not fully backward compatible, Previously set() replaces MAC in list[0], so multiple set() commands end up with single MAC address. So device will filter only one MAC. With #2, after first set(), application will need to add() first, later set() and del() old MAC, if I understand correctly. prev: set(MAC1) set(MAC2) set(MAC3) becomes: set(MAC1) add(MAC2) set(MAC2) del(MAC1) add(MAC3) set(MAC3) del(MAC2) Hence I think this complicates application that wants to just update default MAC. >   > > 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