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 25D6DB0AD for ; Mon, 16 Jun 2014 16:14:01 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 16 Jun 2014 07:14:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,486,1400050800"; d="scan'208";a="556225305" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 16 Jun 2014 07:14:14 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 16 Jun 2014 15:13:32 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.239]) by IRSMSX152.ger.corp.intel.com ([169.254.6.197]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 15:13:31 +0100 From: "Ananyev, Konstantin" To: "Richardson, Bruce" , Chris Wright Thread-Topic: [dpdk-dev] [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF Thread-Index: AQHPhzHQ+mi6qWqFCkWS542452HMOptvR1uAgAATAICABFsEwA== Date: Mon, 16 Jun 2014 14:13:31 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580EFB7358@IRSMSX105.ger.corp.intel.com> References: <20140606235028.189345212@networkplumber.org> <2240300.rVk2eNDOWK@xps13> <20140613102440.19537123@nehalam.linuxnetplumber.net> <20140613175137.GS1384@x220.localdomain> <59AF69C657FD0841A61C55336867B5B01AA36117@IRSMSX103.ger.corp.intel.com> <20140613181403.GT1384@x220.localdomain> <59AF69C657FD0841A61C55336867B5B01AA3616B@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B01AA3616B@IRSMSX103.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:14:02 -0000 Hi Bruce, >> > However, even with that, I would suggest that any limit should be poss= ible to >> override. It's entirely possible that someone max actually want to reser= ve the >> full number of VFs, either because they don't want to use the NIC on the= host at >> all, or because they are happy to use a VF on the host instead. Module >> parameter to allow override might work - and information on it could be = added >> to the error message when we limit the VFs inside the driver. >>=20 >> It's been a while since I've looked at this, but my recollection is >> the PF must be there (basic mailbox handling, for example). >>=20 >> Would you rather a simple warning message as a hint? >I'm not sure about the PF still needing to be there or not - I'm not an ex= pert in that area, so you may indeed be right.=20 >However, as for this patch, I'd probably be ok for now with a version that= queried the max_vfs and limited based on that. If in >future we do need to= add an override it should be trivial to add later-on. I don't think it is a right way to put all this logic into the kernel modul= e: igb_uio doesn't know how many queues user-space PF plans to use for itself. In your example: 16 queues in total, 7 VFsx2queues =3D 14 queues, 2 queues = left to PF. But then user-space PF decides it needs 4 queues and we we would hit the sa= me problem again.=20 I think, that to fix that issue properly we need to do that in userspace PM= D. After rte_eth_dev_init(), we should know how many queues that device has in= total, and how many of them are reserved for VFs. So at rte_eth_dev_configure() we can add a check that number of requested q= ueues doesn't exceed max_queues - vf_reserved_queues and make rte_eth_dev_c= onfigure() to fail, if it does. =20 Konstantin =20