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 BD94BAF85 for ; Fri, 13 Jun 2014 21:21:51 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 13 Jun 2014 12:22:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,472,1400050800"; d="scan'208";a="555227666" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 13 Jun 2014 12:22:04 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.58]) by IRSMSX101.ger.corp.intel.com ([169.254.1.245]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 20:22:03 +0100 From: "Richardson, Bruce" To: Chris Wright Thread-Topic: [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF Thread-Index: AQHPhzAqE+tSWt1HbE+aLvZBFKv/wJtvUxjA///0R4CAACK7kA== Date: Fri, 13 Jun 2014 19:22:03 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B01AA3616B@IRSMSX103.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> In-Reply-To: <20140613181403.GT1384@x220.localdomain> Accept-Language: en-GB, 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: Fri, 13 Jun 2014 19:21:52 -0000 > -----Original Message----- > From: Chris Wright [mailto:chrisw@redhat.com] > Sent: Friday, June 13, 2014 11:14 AM > To: Richardson, Bruce > Cc: Chris Wright; Stephen Hemminger; Thomas Monjalon; dev@dpdk.org > Subject: Re: [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF >=20 > * Richardson, Bruce (bruce.richardson@intel.com) wrote: > > > > > > > -----Original Message----- > > > From: Chris Wright [mailto:chrisw@redhat.com] > > > Sent: Friday, June 13, 2014 10:52 AM > > > To: Richardson, Bruce; Stephen Hemminger > > > Cc: Thomas Monjalon; dev@dpdk.org > > > Subject: [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF > > > > > > To keep from confusing users, cap max VFs at 7, despite PCI SR-IOV co= nfig > > > space showing a max of 8. This reserves a queue pair for the PF. > > > > > > This issue was cited here: > > > > > > http://dpdk.org/ml/archives/dev/2014-April/001832.html > > > > > > Cc: Bruce Richardson > > > Cc: Stephen Hemminger > > > Signed-off-by: Chris Wright > > > --- > > > > > > This is what Linux kernel driver does. I have only > > > compile tested it. Stephen sending to you and Bruce > > > in case you want to Ack and add to your current queue. > > > > > > > Sorry, NAK - at least for this implementation. >=20 > Oh, that's fine. >=20 > > Hardcoding this to 7 is a bad idea, as the actual max number of VFs sup= ported > will depend on the actual hardware used. For someone using an 82599, they= can > have up to 64 VFs, or 63+PF, so limiting so 7 in that case is a major red= uction in > capability. What might work there is querying the max number of VFs and > limiting to max - 1. >=20 > But this is igb_uio, not 82599 (ixgbe). igb_uio is used as the supporting kernel module for both the e1000/igb and = ixgbe pmd implementations (as well as for the forthcoming i40e pmd). Despit= e the name, it's not just for igb-based NICs. >=20 > > However, even with that, I would suggest that any limit should be possi= ble to > override. It's entirely possible that someone max actually want to reserv= e 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 a= dded > 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 exp= ert 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 a= dd an override it should be trivial to add later-on.