From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 639B12B88 for ; Wed, 22 Feb 2017 05:52:08 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 20:52:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,192,1484035200"; d="scan'208";a="827050283" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by FMSMGA003.fm.intel.com with ESMTP; 21 Feb 2017 20:52:07 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Feb 2017 20:52:07 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Feb 2017 20:52:06 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0248.002; Wed, 22 Feb 2017 12:52:04 +0800 From: "Zhang, Qi Z" To: "Yigit, Ferruh" , "Wu, Jingjing" , "Zhang, Helin" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] net/i40e: no more initial VF MAC address Thread-Index: AQHScWf/r0sORIDUo06ruhjaBm+lJKFBH0UAgDOImKA= Date: Wed, 22 Feb 2017 04:52:03 +0000 Message-ID: <039ED4275CED7440929022BC67E706115305EAE6@SHSMSX103.ccr.corp.intel.com> References: <1484703940-2967-1-git-send-email-qi.z.zhang@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYWVjOGI4ZTUtZGU2Mi00OGQzLTk4NWEtNjAxNzNkYjEzZmM0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFFZWJHV3BFWmZMVForNWRkVytkQzlRVlJWUUNndE9Da0hOS1JCTnJDcnc9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/i40e: no more initial VF MAC address 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, 22 Feb 2017 04:52:08 -0000 Hi Ferruh: Sorry to reply this late, I think I missed your email. > -----Original Message----- > From: Yigit, Ferruh > Sent: Saturday, January 21, 2017 1:39 AM > To: Zhang, Qi Z ; Wu, Jingjing ; > Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/i40e: no more initial VF MAC address >=20 > On 1/18/2017 1:45 AM, Qi Zhang wrote: > > During PF initialization, PF will generate an initial mac address for > > VFs, the purpose is to help VF keep a constant mac address between > > startup/shutdown cycles. >=20 > I believe below does not provide permanent MAC address, PF assign a rando= m > mac address to its VFs on each PF initialization. Yes, this is for VF's startup /shutdown cycles only, but that's the origina= l concern from customer. >=20 > > Now this is not > > necessary, since we already provide an API to set VF mac address from > > PF side (rte_pmd_i40e_set_vf_addr). >=20 > rte_pmd_i40e_set_vf_mac_addr? Exactly! >=20 > > Application > > can use this API to lock down VF's mac address. >=20 > As far as I can see how it was (before this patch): >=20 > 1- During PF init, assign random MAC to VFs. > 2- Application can overwrite VF MAC address with above API. > 3- During VF init, if there is a valid MAC assigned by PF use it. > 4- During VF init, if PF not assigned MAC, assign a random one. >=20 > So this patch removes above step 1. Yes, we remove step 1 intentionally to align with kernel PF driver's behavi= or,=20 because for kernel VF, during initialization, once it found PF already assi= gned a valid MAC, it cannot be changed from VF anymore but if it is not a valid address, VF is given the permission to change it. >=20 > Overall even if application will explicitly assign a MAC to VF or not, VF= will have > a valid MAC address. So patch looks good, just please reword commit log t= o > describe above. Sure, I will update the commit log >=20 > > This change also sync DPDK PF's behavior with kernel driver. > > > > Signed-off-by: Qi Zhang > > --- > > drivers/net/i40e/i40e_pf.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/net/i40e/i40e_pf.c b/drivers/net/i40e/i40e_pf.c > > index ddfc140..4e05dca 100644 > > --- a/drivers/net/i40e/i40e_pf.c > > +++ b/drivers/net/i40e/i40e_pf.c > > @@ -1053,7 +1053,6 @@ i40e_pf_host_init(struct rte_eth_dev *dev) > > ret =3D i40e_pf_host_vf_reset(&pf->vfs[i], 0); > > if (ret !=3D I40E_SUCCESS) > > goto fail; > > - eth_random_addr(pf->vfs[i].mac_addr.addr_bytes); > > } > > > > /* restore irq0 */ > > Regards Qi