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 5EF1CA0C47; Tue, 12 Oct 2021 09:14:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2576D40142; Tue, 12 Oct 2021 09:14:29 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id A1DCE4003C for ; Tue, 12 Oct 2021 09:14:27 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 550045C01B6; Tue, 12 Oct 2021 03:14:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 12 Oct 2021 03:14:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= aA6y8Ns0jsFJprJee8R435dU0wqFlR8GzLk+XQoQlCM=; b=aBiSQ9yiZ0bsevxP AZny4njBnv8qf+o5vLlA+FlLnyR1CzscAFUOOo4znKMUA+Kxr5kQHUL/J/k30bep Pcwa5rBy6XSL6Ai9LrKiH+THTpjzmToXQIQy/spwwR5st+v/FcTGBMkLGjkGjUq/ mULob7xNC2Vg1rP0xHUy3c6c3Q1WtFUSCHbaB9/CMG2JdNg1DI59dNQS0h/pSX2m n8NlLyhHrjzUGu7OTJhhuguenbTtQz0mHeK+yo05NYivyAoF44O68x1UFpoje8ai 2s5IzjFjrxiSRObC8D0l6dah2fZ5esrR7IwIGDRsMXpcsuE9nhAQPZNP6xheHIN0 54+/sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=aA6y8Ns0jsFJprJee8R435dU0wqFlR8GzLk+XQoQl CM=; b=bbXA+nwesvGckRtyKCSC66G7rhnW7T9A/G4VockDBQv1EXpAW3J3VjnXl ETqmYg6Xtp6RSOVa7rd2fWa2fNbR+iOWBs5UNJKDeKwlYx/xY25A38U7s+AjNZwh 6d7WEa26yvOjwGEZLn7dHIActYiMBFq+BIP9Tglsw2/OrsNjbLpt13u86mrMAjof r5URqcMH2vLU5yp9/W8KW4MC8qPx42b1oX6plwLPXOEFG5abtuqfBtUvzNFpeOe6 I8yUw+Y+7/zFLlScl12PdQL+QxW03sC5fhaFvhXi19oyuZtzt15uYmKoJam1Z3ag TfU3lE61mAnfTkzGcgQHZcf0Uv2Tg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtjedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 03:14:26 -0400 (EDT) From: Thomas Monjalon To: "Min Hu (Connor)" , "lihuisong (C)" Cc: dev@dpdk.org, ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru Date: Tue, 12 Oct 2021 09:14:23 +0200 Message-ID: <2863918.lGjFY7q0R8@thomas> In-Reply-To: References: <20210922033630.41130-1-humin29@huawei.com> <2044667.cjkjM3ByYo@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix one MAC address occupies two index in mac addrs 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 Sender: "dev" 12/10/2021 04:58, lihuisong (C): > =E5=9C=A8 2021/10/11 18:35, Thomas Monjalon =E5=86=99=E9=81=93: > > 11/10/2021 11:28, Min Hu (Connor): > >> From: Huisong Li > >> > >> 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 > >> Signed-off-by: Min Hu (Connor) > >> --- > >> + /* > >> + * 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. >=20 > 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. > > Another comment, > > If we remove the duplicate, we may have to copy to previous default one > > to avoid completely deleting the previous default address. >=20 > That's not necessary. >=20 > Because the previous default address has been removed from hardware. >=20 > After the default MAC address is modified, the previous default one is=20 > 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. > > Not sure what should be the behaviour.