From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by dpdk.org (Postfix) with ESMTP id 96C5D2BC9 for ; Wed, 13 Sep 2017 04:38:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2419; q=dns/txt; s=iport; t=1505270290; x=1506479890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4WDggIZh32wbiir5ndVflJRLWHsweMSpi/0lHpQ7Hkc=; b=ShjnbFOuTQ6s0AjJhHLefx5HTnU72Q2/EL4r/8FovGrOJr06768XxT1F 1+ksWW77eW0T/yV8JmW8X6uGJkBz5BQy1JaOIqqfHM70dp43ecBJgHbo4 rg9L768NLnh9kJ5wNDA+pRRyl3P5pSK77gro6WpYXAp5ORfLylX7L4+6q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAADBmLhZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUhUSB44SkCWBdJFChGYOggQKhT4ChEQ/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEDAScTPwwEAgEIFSEJBzIUEQIEAQ0FCIohCK5BOos5AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMrggKBUIULhEAfhgwFoHQClEeCHIVoindIlDoCERkBgTg?= =?us-ascii?q?BHziBDXcVh2V2h0WBMoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,385,1500940800"; d="scan'208";a="294675981" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 02:38:09 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8D2c9Nf012918 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Sep 2017 02:38:09 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 12 Sep 2017 21:38:08 -0500 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1263.000; Tue, 12 Sep 2017 21:38:08 -0500 From: "David Harton (dharton)" To: "Xing, Beilei" , David Harton , "Wu, Jingjing" CC: "dev@dpdk.org" Thread-Topic: [PATCH v2] i40e: fix i40evf_add_mac_addr to permit multicast addresses Thread-Index: AQHTK8ddfBmqlB6Ud0emDxm8cagyqKKyafeA//+ulfA= Date: Wed, 13 Sep 2017 02:38:08 +0000 Message-ID: References: <20170822222146.36912-1-dharton@cisco.com> <20170912130210.18288-1-dharton@cpp-rtpbld-31.cpprtplab> <94479800C636CB44BD422CB454846E013201BD5A@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <94479800C636CB44BD422CB454846E013201BD5A@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.174.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2] i40e: fix i40evf_add_mac_addr to permit multicast addresses 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: Wed, 13 Sep 2017 02:38:11 -0000 Hi Beilei, > -----Original Message----- > From: Xing, Beilei [mailto:beilei.xing@intel.com] >=20 > Hi Harton, >=20 > > -----Original Message----- > > From: David Harton [mailto:dharton@cpp-rtpbld-31.cpprtplab] > > > > From: David Harton > > > > The i40e maintains a single MAC filter table for both unicast and > > multicast addresses. The i40e_validate_mac_addr function was > > preventing multicast addresses from being added to the table via > > i40evf_add_mac_addr. Fixed the issue by adjusting the check in > i40evf_add_mac_addr. > > > > Fixes: 4861cde46116 ("i40e: new poll mode driver") > > Fixes: 97ac72aa71a9 ("i40e: support setting VF MAC address") > > > > Signed-off-by: David Harton > > --- > > > > v2 > > * Removed multicast check in i40evf_add_mac_addr. > > > > v1 > > * Removed multicast check in i40e_validate_mac_addr. > > > > drivers/net/i40e/i40e_ethdev_vf.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/i40e/i40e_ethdev_vf.c > > b/drivers/net/i40e/i40e_ethdev_vf.c > > index f6d8293..5916d11 100644 > > --- a/drivers/net/i40e/i40e_ethdev_vf.c > > +++ b/drivers/net/i40e/i40e_ethdev_vf.c > > @@ -888,7 +888,7 @@ i40evf_add_mac_addr(struct rte_eth_dev *dev, > > int err; > > struct vf_cmd_info args; > > > > - if (i40e_validate_mac_addr(addr->addr_bytes) !=3D I40E_SUCCESS) { > > + if (is_zero_ether_addr(addr) !=3D I40E_SUCCESS) { >=20 > Thanks for the patch, there's some mistake with my last comment. Actually, I think the logic above works but I do agree it is confusing but I wanted to use your suggestion to speed up the process. :) > * @return > * True (1) if the given ethernet address is filled with zeros; > * false (0) otherwise. > */ > According to the comment of is_zero_ether_addr function, return value > should be 0 or 1. > So you should use if (!is_zero_ether_addr(addr)) here. I don't think so. I think the logic that should be used is if (is_zero_ether_addr(addr)) { because we want to report an error if the addr is all 0's. Please let me know if you agree and I'll post this patch instead. Thanks, Dave >=20 > > PMD_DRV_LOG(ERR, "Invalid mac:%x:%x:%x:%x:%x:%x", > > addr->addr_bytes[0], addr->addr_bytes[1], > > addr->addr_bytes[2], addr->addr_bytes[3], > > -- > > 2.10.3.dirty