From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhenyu Wang Subject: Re: [libvirt] [PATCH v2 0/4] New mdev type handling for aggregated resources Date: Mon, 30 Jul 2018 10:11:48 +0800 Message-ID: <20180730021148.GV1267@zhen-hp.sh.intel.com> References: <20180620074039.10539-1-zhenyuw@linux.intel.com> <20180720021928.15343-1-zhenyuw@linux.intel.com> <20180724114440.76564e75@t450s.home> <20180726135028.GG11030@beluga.usersys.redhat.com> <20180726173007.3f2b9d09.cohuck@redhat.com> <20180726154345.GI11030@beluga.usersys.redhat.com> <20180726180410.1dffccde.cohuck@redhat.com> <20180727144555.GJ26747@beluga.usersys.redhat.com> Reply-To: Zhenyu Wang Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4191187917535805230==" Cc: kevin.tian@intel.com, kvm@vger.kernel.org, Cornelia Huck , kwankhede@nvidia.com, Zhenyu Wang , libvirt-list@redhat.com, intel-gvt-dev@lists.freedesktop.org To: Erik Skultety Return-path: In-Reply-To: <20180727144555.GJ26747@beluga.usersys.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com List-Id: kvm.vger.kernel.org --===============4191187917535805230== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="It8I9WCLqdSMcwR+" Content-Disposition: inline --It8I9WCLqdSMcwR+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018.07.27 16:45:55 +0200, Erik Skultety wrote: > On Thu, Jul 26, 2018 at 06:04:10PM +0200, Cornelia Huck wrote: > > On Thu, 26 Jul 2018 17:43:45 +0200 > > Erik Skultety wrote: > > > > > On Thu, Jul 26, 2018 at 05:30:07PM +0200, Cornelia Huck wrote: > > > > One thing I noticed is that we have seem to have an optional (?) > > > > vendor-driver created "aggregation" attribute (which always prints > > > > "true" in the Intel driver). Would it be better or worse for libvir= t if > > > > it contained some kind of upper boundary or so? Additionally, would= it > > > > > > Can you be more specific? Although, I wouldn't argue against data tha= t conveys > > > some information, since I would treat the mere presence of the option= al > > > attribute as a supported feature that we can expose. Therefore, addit= ional > > > *structured* data which sets clear limits to a certain feature is onl= y a plus > > > that we can expose to the users/management layer. > > > > My question is what would be easiest for libvirt: > > > > - "aggregation" attribute only present when driver supports aggregation > > (possibly containing max number of resources to be aggregated) > > - "aggregation" attribute always present; contains '1' if driver does > > not support aggregation and 'm' if driver can aggregate 'm' resources >=20 > Both are fine from libvirt's POV, but IMHO the former makes a bit more se= nse > and I'm in favour of that one, IOW the presence of an attribute denotes a= new > functionality which we can report, if it's missing, the feature is clearly > lacking- I don't think we (libvirt) should be reporting the value 1 expli= citly > in the XML if the feature is missing, we can assume 1 as the default. >=20 Good I'll adhere to that, thanks! --=20 Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 --It8I9WCLqdSMcwR+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTXuabgHDW6LPt9CICxBBozTXgYJwUCW15z5AAKCRCxBBozTXgY JzLVAJ0ahbemtEXYbkDSV8l28BpUIWDujgCeLr6QFHEodsc2wREhBgQqwkU37Bc= =hV/2 -----END PGP SIGNATURE----- --It8I9WCLqdSMcwR+-- --===============4191187917535805230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4191187917535805230==--