All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: kevin.tian@intel.com, kvm@vger.kernel.org,
	Cornelia Huck <cohuck@redhat.com>,
	libvirt-list@redhat.com, kwankhede@nvidia.com,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [libvirt] [PATCH v2 4/4] Documentation/vfio-mediated-device.txt: update for aggregation attribute
Date: Thu, 26 Jul 2018 21:30:50 -0600	[thread overview]
Message-ID: <20180726213039.4bb1b59f@t450s.home> (raw)
In-Reply-To: <20180727021658.GN1267@zhen-hp.sh.intel.com>

On Fri, 27 Jul 2018 10:16:58 +0800
Zhenyu Wang <zhenyuw@linux.intel.com> wrote:

> On 2018.07.26 17:46:40 +0200, Cornelia Huck wrote:
> > On Fri, 20 Jul 2018 10:19:28 +0800
> > Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> >   
> > > Update mdev doc on new aggregration attribute and instances attribute
> > > for mdev.
> > > 
> > > Cc: Kirti Wankhede <kwankhede@nvidia.com>
> > > Cc: Alex Williamson <alex.williamson@redhat.com>
> > > Cc: Kevin Tian <kevin.tian@intel.com>
> > > Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
> > > ---
> > >  Documentation/vfio-mediated-device.txt | 39 ++++++++++++++++++++++----
> > >  1 file changed, 33 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/Documentation/vfio-mediated-device.txt b/Documentation/vfio-mediated-device.txt
> > > index c3f69bcaf96e..9ec9495dcbe7 100644
> > > --- a/Documentation/vfio-mediated-device.txt
> > > +++ b/Documentation/vfio-mediated-device.txt
> > > @@ -211,12 +211,20 @@ Directories and files under the sysfs for Each Physical Device
> > >    |     |   |--- description
> > >    |     |   |--- [devices]
> > >    |     |--- [<type-id>]
> > > -  |          |--- create
> > > -  |          |--- name
> > > -  |          |--- available_instances
> > > -  |          |--- device_api
> > > -  |          |--- description
> > > -  |          |--- [devices]
> > > +  |     |    |--- create
> > > +  |     |    |--- name
> > > +  |     |    |--- available_instances
> > > +  |     |    |--- device_api
> > > +  |     |    |--- description
> > > +  |     |    |--- [devices]
> > > +  |     |--- [<type-id>]
> > > +  |     |    |--- create
> > > +  |     |    |--- name
> > > +  |     |    |--- available_instances
> > > +  |     |    |--- device_api
> > > +  |     |    |--- description
> > > +  |     |    |--- <aggregation>
> > > +  |     |    |--- [devices]
> > >  
> > >  * [mdev_supported_types]
> > >  
> > > @@ -260,6 +268,19 @@ Directories and files under the sysfs for Each Physical Device
> > >    This attribute should show brief features/description of the type. This is
> > >    optional attribute.
> > >  
> > > +* <aggregation>
> > > +
> > > +  The description is to show feature for one instance of the type. <aggregation>  
> > 
> > You are talking about "one instance" here. Can this be different for
> > the same type with different physical devices?
> >  
> 
> I would expect for normal mdev types, driver might expose like x2, x4, x8 types
> which split hw resource equally. But for type with aggregation feature, it can
> set user wanted number of instances. Sorry maybe my use of word was not clear, how
> about "one example of type"?
> 
> > > +  is an optional attributes to show that [<type-id>]'s instances can be
> > > +  aggregated to be assigned for one mdev device. Set number of instances by
> > > +  appending "instances=N" parameter for create. Instances number can't exceed
> > > +  available_instances number. Without "instances=N" parameter will be default
> > > +  one instance to create.  
> > 
> > Could there be a case where available_instances is n, but aggregation
> > is only supported for a value m < n? If yes, should m be discoverable
> > via the "aggregation" attribute?
> >  
> 
> I don't think there could be a case for that. As for aggregation type,
> it represents minimal resource allocated for a singleton, I can't see
> any reason for possible m < n.

Let's think about the interface beyond the immediate needs.  It seems
perfectly reasonable to me to think that a vendor driver might have a
large number of resources available, the ability to aggregate resources
beyond what's practical to enumerate with discrete types, yet have an
upper bound of how many resources can be aggregated for a single
instance.  Thanks,

Alex

  reply	other threads:[~2018-07-27  3:30 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20  7:40 [libvirt] [RFC PATCH 0/2] Add new mdev type for aggregated resources Zhenyu Wang
2018-06-20  7:40 ` [libvirt] [RFC PATCH 1/2] vfio/mdev: Add new instances parameters for mdev create Zhenyu Wang
2018-06-20  7:40 ` [libvirt] [RFC PATCH 2/2] drm/i915/gvt: Add new aggregation type Zhenyu Wang
2018-06-21 14:27 ` [libvirt] [RFC PATCH 0/2] Add new mdev type for aggregated resources Kirti Wankhede
2018-06-21 15:00   ` Alex Williamson
2018-06-22  7:42     ` Zhenyu Wang
2018-06-22 13:59       ` Kirti Wankhede
2018-07-20  2:19 ` [libvirt] [PATCH v2 0/4] New mdev type handling " Zhenyu Wang
2018-07-20  2:19   ` [libvirt] [PATCH v2 1/4] vfio/mdev: Add new instances parameter for mdev create Zhenyu Wang
2018-07-26 15:37     ` Cornelia Huck
2018-07-20  2:19   ` [libvirt] [PATCH v2 2/4] vfio/mdev: Add mdev device instances attribute Zhenyu Wang
2018-07-20  2:19   ` [libvirt] [PATCH v2 3/4] drm/i915/gvt: Add new aggregation type support Zhenyu Wang
2018-07-20  2:19   ` [libvirt] [PATCH v2 4/4] Documentation/vfio-mediated-device.txt: update for aggregation attribute Zhenyu Wang
2018-07-26 15:46     ` Cornelia Huck
2018-07-27  2:16       ` Zhenyu Wang
2018-07-27  3:30         ` Alex Williamson [this message]
2018-07-27 11:49         ` Cornelia Huck
2018-07-24 17:44   ` [libvirt] [PATCH v2 0/4] New mdev type handling for aggregated resources Alex Williamson
2018-07-26 13:50     ` Erik Skultety
2018-07-26 14:29       ` Alex Williamson
2018-07-26 16:00         ` Erik Skultety
2018-07-26 15:30       ` Cornelia Huck
2018-07-26 15:43         ` Erik Skultety
2018-07-26 16:04           ` Cornelia Huck
2018-07-27 14:45             ` Erik Skultety
2018-07-30  2:11               ` Zhenyu Wang
2018-07-26 15:51         ` Alex Williamson
2018-07-26 15:59           ` Cornelia Huck
2018-07-27  2:01     ` Zhenyu Wang
2018-10-08  3:19   ` Tian, Kevin
2018-10-08  5:08     ` Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 0/6] VFIO mdev aggregated resources handling Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 1/6] vfio/mdev: Add new "aggregate" parameter for mdev create Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 2/6] vfio/mdev: Add "aggregation" attribute for supported mdev type Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 3/6] vfio/mdev: Add "aggregated_instances" attribute for supported mdev device Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 4/6] Documentation/vfio-mediated-device.txt: Update for vfio/mdev aggregation support Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 5/6] Documentation/ABI/testing/sysfs-bus-vfio-mdev: " Zhenyu Wang
2018-10-17  9:00   ` [libvirt] [PATCH v3 6/6] drm/i915/gvt: Add new type with " Zhenyu Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180726213039.4bb1b59f@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=libvirt-list@redhat.com \
    --cc=zhenyuw@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.