From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by dpdk.org (Postfix) with ESMTP id 99CE02C49 for ; Fri, 10 Mar 2017 10:02:32 +0100 (CET) Received: by mail-wr0-f172.google.com with SMTP id u108so60556939wrb.3 for ; Fri, 10 Mar 2017 01:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=nRcRJXMDPkgX7dAvUyOpCyYglH/ZKQj27gbO+OqQIE4=; b=yPV5j0nhSGAMEDNgg5N37Yl1biBrptU/kF51QnzfLcbZ+9NUoF23XxJN1W2lJae0cu UZsFeCVyp5pG3HQAh0hfFcvn0YQCB+ovEvA2hNz1kzJlpYk5EwQz2zud6MLKmSwOSUfP BmH4CY5lW6eoeWaZbwaY0JbcOSlrAM8WzEfsPC6U6dCve9q7Fz32vX7k8vRcmUAlzERO 4lM5Xw2mYOv98KQ092UiDfC4NA/DpJyLVMdhHsUS1WQAxhf/jeR9JN5lvPObKw4JoZE1 PeKdHpcBr6XA1xuQfbpAMaOznMFRbyNFiWujO4/6GtJ/Sn1gGb0E87SBjE8rlbyNn7xh AmZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=nRcRJXMDPkgX7dAvUyOpCyYglH/ZKQj27gbO+OqQIE4=; b=Q9v7XsekSd+busH/07+ACQ58IFUd0YRddAtlQ9BRExZ/W+OyfOtF7yjvzVloj7fweQ B+78yKz6Uau1zC+9oAe4WEPAPCaOU5ZkSMMCbxX3dGv+RmKxGavPdHYrvZe1wXf40aDb RBGDDlMXbxCvXEKewINrpcQF26OS82gkrAsvWZrqVxl6BCv8J7SJvq+Rg/8+KFYxX9Wh QjA/zsMZyQ/0pn36cf3zefQQa53Kg+BagnwDNSPwWyHrxfJjtIW/aCAQLx022J5yL1kz YC6dYKkQWiLYX/FIU4CmUw0iFDNrs/m4XE7Y1YcLQmu1fd4InjvPHNx9Y4EeGuDMWMxZ BoRQ== X-Gm-Message-State: AMke39mScnR7ucm3kh+GX3SU+s7RfK8AnaP7xnPEel4vQLNeUvkHW9cnGiuWUxnbhuuquLZs X-Received: by 10.223.149.37 with SMTP id 34mr15108998wrs.107.1489136552286; Fri, 10 Mar 2017 01:02:32 -0800 (PST) Received: from paques.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id z198sm2324659wmz.24.2017.03.10.01.02.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 01:02:32 -0800 (PST) Date: Fri, 10 Mar 2017 10:01:52 +0100 From: Pascal Mazon To: Ferruh Yigit Cc: keith.wiles@intel.com, dev@dpdk.org Message-ID: <20170310100152.7b9297db@paques.dev.6wind.com> In-Reply-To: <53d1a212-9354-ee10-72fb-2f8bfb1d29f6@intel.com> References: <1488904298-31395-2-git-send-email-pascal.mazon@6wind.com> <53d1a212-9354-ee10-72fb-2f8bfb1d29f6@intel.com> Organization: 6WIND X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 1/6] net/tap: add MAC address management ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 09:02:32 -0000 On Thu, 9 Mar 2017 14:05:51 +0000 Ferruh Yigit wrote: > On 3/7/2017 4:31 PM, Pascal Mazon wrote: > > Set a random MAC address when probing the device, as to not leave an > > empty MAC in pmd->eth_addr. > > > > This MAC will be set on the tap netdevice as soon as it's been > > created using tun_alloc(). As the tap_mac_add() function depend on > > the fd in the first rxq, move code from tun_alloc() to > > tap_setup_queue(), after it's been set. > > > > Signed-off-by: Pascal Mazon > > --- > > doc/guides/nics/features/tap.ini | 1 + > > drivers/net/tap/rte_eth_tap.c | 97 > > ++++++++++++++++++++++++++++++++++------ 2 files changed, 85 > > insertions(+), 13 deletions(-) > > > > diff --git a/doc/guides/nics/features/tap.ini > > b/doc/guides/nics/features/tap.ini index f4aca6921ddc..d9b47a003654 > > 100644 --- a/doc/guides/nics/features/tap.ini > > +++ b/doc/guides/nics/features/tap.ini > > @@ -9,6 +9,7 @@ Jumbo frame = Y > > Promiscuous mode = Y > > Allmulticast mode = Y > > Basic stats = Y > > +Unicast MAC filter = Y > > Other kdrv = Y > > ARMv7 = Y > > ARMv8 = Y > > diff --git a/drivers/net/tap/rte_eth_tap.c > > b/drivers/net/tap/rte_eth_tap.c index ece3a5fcc897..1e46ee36efa2 > > 100644 --- a/drivers/net/tap/rte_eth_tap.c > > +++ b/drivers/net/tap/rte_eth_tap.c > > @@ -63,6 +63,8 @@ > > #define RTE_PMD_TAP_MAX_QUEUES 1 > > #endif > > > > +#define RTE_PMD_TAP_MAX_MAC_ADDRS 1 > > mac_addr_add and mac_addr_remove not really supported, because only > one MAC is supported. For mac_addr_add() all indexes other than 0 > will give an error. So only mac_addr_set is supported. > > For this case what is the benefit of implementing these functions and > claim support, instead of just leaving mac_addr_add and > mac_addr_remove NULL? > Well, I wanted to implement those along with the mac_addr_set, as they all dealt with mac addresses. But you're right, I might as well leave the ops NULL. I'll send a new version reflecting this. > > <...> > > > + if (qid == 0) { > > + /* > > + * tap_setup_queue() is called for both tx and rx. > > + * Let's use dev->data->r/tx_queues[qid] to > > determine if init > > + * has already been done. > > + */ > > + if (dev->data->rx_queues[qid] && > > dev->data->tx_queues[qid]) > > + return fd; > > + > > + tap_mac_set(dev, &pmd->eth_addr); > > What is the reason of changing behavior here? > > Tap devices assigned random MAC by kernel, and previous implementation > was reading that value and using it for DPDK. > > Now kernel assigns a random MAC, and DPDK overwrites it another random > MAC, previous implementation was simpler I think. > > It is OK to move this code tap_setup_queue(), I just missed the > benefit of overwriting with DPDK random MAC? > > <...> As far as I remember, I did it because somewhere the mac_addr_set was checked as part of reconfiguration, which happenened before queue setup was done. The default mac address (dev->data->mac_addrs[0]) got set to 0 and later call for the default mac address tried using this mac address. Or something along those lines. I'll definitely re-take a closer look at all this for my next version. Regards, Pascal