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 4606BA0C43; Wed, 20 Oct 2021 12:15:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C010A40687; Wed, 20 Oct 2021 12:15:33 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id EF0BE40142 for ; Wed, 20 Oct 2021 12:15:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634724932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HTb0ntO1/QdfBlbuW+ELWDiJUMoVsyLL2TwrPyPkpaI=; b=Id/QIuN803kKYUEiv+EpVtDK0btrHqJnkUvLf7pGbOvuUNYodSoXapukvOonawie2g+fMx FRGtJ5RODIhU1kgcBkaQudQyStl2rRjoG7AqpZef6W9Wpc4wSBmtGQ/0CQC9kTcywUwdU7 Gvp+TqYI0JrlMYQq/1kWNWFnXONqyR4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-507-HcN06hZeMrKJllnlol4eqQ-1; Wed, 20 Oct 2021 06:15:31 -0400 X-MC-Unique: HcN06hZeMrKJllnlol4eqQ-1 Received: by mail-wm1-f70.google.com with SMTP id k6-20020a7bc306000000b0030d92a6bdc7so2883321wmj.3 for ; Wed, 20 Oct 2021 03:15:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=HTb0ntO1/QdfBlbuW+ELWDiJUMoVsyLL2TwrPyPkpaI=; b=Ef5OVM6iMLP5uOEfmfvRK8jv3DS3Mv2MOhc6XmQCw/YQVu0RQC1o/ct2aH4xJQijlL xq2PNwZHhtYXxKlhg5/7WyZf6lJcuQGSpb98DqfCWkacDeNGhOpg60AN1YVLTfnh1DPX eNXsSlBwBv4Ulu/XBVlPVBMCRXWWJOOR2eXlB0oezuSMQw0lINt1QlahHdxCxpbKWTuA jfUGenMfR2W146pUZzLpZMerROOqrK356LFNyQYSCERnSNM4eTBfiioxRze6Iie/butC ITDIJX/Um5Bb806bZiUgRw14nBf07wDcqJwseLSLrPWvoBl5akcTfMhR+256p8rzN9a+ 12ng== X-Gm-Message-State: AOAM533P1brCPh0dXSLXU41UpzQTUU/J2Wbudxqn6n67E0w4SqcoEOH5 4Z5cvfKnOYKXgK4K5YanT+VKbSr0MpAsVW1ScpEUFbjZhPARIa53+UAoADrS0Z7yDGUGhg3mcZe spcI= X-Received: by 2002:a1c:7fd0:: with SMTP id a199mr12565935wmd.96.1634724929956; Wed, 20 Oct 2021 03:15:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyI46r4wLUFXj4LL1nkUkAHITYVPC710AHxX3+W0Dm4k6kppjL8ncK5b2E/TPBsE8Uw9xQsOA== X-Received: by 2002:a1c:7fd0:: with SMTP id a199mr12565910wmd.96.1634724929703; Wed, 20 Oct 2021 03:15:29 -0700 (PDT) Received: from [192.168.0.36] ([78.19.105.235]) by smtp.gmail.com with ESMTPSA id i203sm4641140wma.48.2021.10.20.03.15.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 03:15:29 -0700 (PDT) Message-ID: <31cd92b1-d388-bd50-963a-8a85a924c0a2@redhat.com> Date: Wed, 20 Oct 2021 11:15:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: Ferruh Yigit , "lihuisong (C)" , "Min Hu (Connor)" , dev@dpdk.org Cc: thomas@monjalon.net References: <20210922033630.41130-1-humin29@huawei.com> <20211011092811.55172-1-humin29@huawei.com> <8decd3d4-4370-2f89-44d5-3e0dd848a628@intel.com> From: Kevin Traynor In-Reply-To: <8decd3d4-4370-2f89-44d5-3e0dd848a628@intel.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=ktraynor@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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" On 20/10/2021 08:41, Ferruh Yigit wrote: > On 10/20/2021 7:49 AM, lihuisong (C) wrote: >> Hi Ferruh >> >> 在 2021/10/20 1:45, Ferruh Yigit 写道: >>> On 10/11/2021 10:28 AM, Min Hu (Connor) wrote: >>>> 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[]. >>>> >>> >>> Hi Connor, >>> >>> I see the problem, but can you please clarify what is the impact to the end user? >>> >>> If application does as following: >>>   rte_eth_dev_mac_addr_add(MAC1); >>>   rte_eth_dev_mac_addr_add(MAC2); >>>   rte_eth_dev_mac_addr_add(MAC3); >>>   rte_eth_dev_default_mac_addr_set(MAC2); >>> >>> The 'dev->data->mac_addrs[]' will have: "MAC2,MAC2,MAC3" which has 'MAC2' duplicated. >>> >>> Will this cause any problem for the application to receive the packets >>> with 'MAC2' address? >>> Or is the only problem one extra space used in 'dev->data->mac_addrs[]' >>> without any other impact to the application? >> I think it's just a waste of space. > > True, it is a waste. But if there is no other visible user impact, we can > handle the issue with lower priority and clarifying the impact in commit log > helps to others. > >>> >>>> 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) >>>> --- >>>> v2: >>>> * fixed commit log. >>>> --- >>>>   lib/ethdev/rte_ethdev.c | 15 +++++++++++++++ >>>>   1 file changed, 15 insertions(+) >>>> >>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c >>>> index 028907bc4b..7faff17d9a 100644 >>>> --- a/lib/ethdev/rte_ethdev.c >>>> +++ b/lib/ethdev/rte_ethdev.c >>>> @@ -4340,6 +4340,7 @@ int >>>>   rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr) >>>>   { >>>>       struct rte_eth_dev *dev; >>>> +    int index; >>>>       int ret; >>>>         RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV); >>>> @@ -4361,6 +4362,20 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr) >>>>       if (ret < 0) >>>>           return ret; >>>>   +    /* >>>> +     * 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[]. >>>> +     */ >>>> +    index = eth_dev_get_mac_addr_index(port_id, addr); >>>> +    if (index > 0) { >>>> +        /* remove address in NIC data structure */ >>>> +        rte_ether_addr_copy(&null_mac_addr, >>>> +                    &dev->data->mac_addrs[index]); >>>> +        /* reset pool bitmap */ >>>> +        dev->data->mac_pool_sel[index] = 0; >>>> +    } >>>> + >>> >>> Here only 'dev->data->mac_addrs[]' array is updated and it assumes >>> driver removes similar duplication itself, but I am not sure if this is >>> valid for all drivers. >>> >>> If driver is not removing the duplicate in the HW configuration, the driver >>> config and 'dev->data->mac_addrs[]' will diverge, which is not good. >> The same MAC address does not occupy two HW entries, which is also a >> waste for HW. After all, HW entry resources are also limited. >> The PMD should also take this into account. >> So, I think, we don't have to think about it here. > > I am not sure all PMD take this into account, I briefly checked the ixgbe > code and I am not sure if it handles this. > > Also it is possible to think that this responsibility is pushed to the > application, like application should remove a MAC address before setting > it as default MAC... > Yes, the API view is more important than saving one entry in an array. From API perspective with this patch, set_default(MAC1) add(MAC2) add(MAC3) add(MAC4) default=MAC1, Filters=MAC2, MAC3, MAC4 set_default(MAC2) default=MAC2, Filters= MAC3, MAC4 set_default(MAC3) default=MAC3, Filters= MAC4 set_default(MAC4) default=MAC4, Filters= set_default(MAC5) default=MAC5, Filters= Did I get it right? If so, it seems wrong to silently remove the filters. In which case, it would be easier to just not remove them in the first place (current behaviour). If they really need to be removed from the filter list when they are set_default(), then perhaps they should be restored to it when there is a new set_default(). >>> >>> What about following logic to be sure HW configuration and >>> 'dev->data->mac_addrs[]' is same: >>> >>>   index = eth_dev_get_mac_addr_index(port_id, addr); >>>   if (index > 0) >>> rte_eth_dev_mac_addr_remove(port_id, addr); >>>   (*dev->dev_ops->mac_addr_set)(dev, addr); >> The logic above seems to be good. But if .mac_addr_set() failed to >> execute, the addr has been removed from HW and 'dev->data->mac_addrs[]'. >> It's not good. >> > > Agree. So may need to get a copy of 'addr' and add it back on failure. > > The concern I have to call 'rte_eth_dev_mac_addr_remove()' after > 'dev_ops->mac_addr_set()' is, it may result different behavior on > different PMDs. > For the PMDs that clean the redundant MAC address via 'dev_ops->mac_addr_set()' > may try to remove (although it will fail) the new set default MAC address. > That is why first remove the MAC and later add it back as default > seems safer to me. > >> Hope for your reply.  Thanks. >>>>       /* Update default address in NIC data structure */ >>>>       rte_ether_addr_copy(addr, &dev->data->mac_addrs[0]); >>>> >>> >>> . >