From mboxrd@z Thu Jan  1 00:00:00 1970
From: Cornelia Huck <cohuck@redhat.com>
Subject: Re: [libvirt] [PATCH v2 0/4] New mdev type handling for aggregated
 resources
Date: Thu, 26 Jul 2018 18:04:10 +0200
Message-ID: <20180726180410.1dffccde.cohuck@redhat.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kevin.tian@intel.com, kvm@vger.kernel.org, libvirt-list@redhat.com,
	Zhenyu Wang <zhenyuw@linux.intel.com>, kwankhede@nvidia.com,
	intel-gvt-dev@lists.freedesktop.org
To: Erik Skultety <eskultet@redhat.com>
Return-path: <libvir-list-bounces@redhat.com>
In-Reply-To: <20180726154345.GI11030@beluga.usersys.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/libvir-list>
List-Post: <mailto:libvir-list@redhat.com>
List-Help: <mailto:libvir-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=subscribe>
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
List-Id: kvm.vger.kernel.org

On Thu, 26 Jul 2018 17:43:45 +0200
Erik Skultety <eskultet@redhat.com> 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 libvirt 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 that conveys
> some information, since I would treat the mere presence of the optional
> attribute as a supported feature that we can expose. Therefore, additional
> *structured* data which sets clear limits to a certain feature is only 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