KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Christophe de Dinechin <cdupontd@redhat.com>
Cc: Sylvain Bauza <sbauza@redhat.com>,
	Pavel Hrdina <phrdina@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Skultety <eskultet@redhat.com>,
	Libvirt Devel <libvir-list@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Kirti Wankhede <kwankhede@nvidia.com>
Subject: Re: [libvirt] mdevctl: A shoestring mediated device management and persistence utility
Date: Fri, 14 Jun 2019 08:23:28 -0600
Message-ID: <20190614082328.540a04ea@x1.home> (raw)
In-Reply-To: <4C4B64A0-E017-436C-B13E-E60EABC6F5F1@redhat.com>

On Fri, 14 Jun 2019 11:54:42 +0200
Christophe de Dinechin <cdupontd@redhat.com> wrote:

> > On 13 Jun 2019, at 18:35, Alex Williamson <alex.williamson@redhat.com> wrote:
> > 
> > On Thu, 13 Jun 2019 18:17:53 +0200
> > Christophe de Dinechin <cdupontd@redhat.com> wrote:
> >   
> >>> On 24 May 2019, at 01:20, Alex Williamson <alex.williamson@redhat.com> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Currently mediated device management, much like SR-IOV VF management,
> >>> is largely left as an exercise for the user.  This is an attempt to
> >>> provide something and see where it goes.  I doubt we'll solve
> >>> everyone's needs on the first pass, but maybe we'll solve enough and
> >>> provide helpers for the rest.  Without further ado, I'll point to what
> >>> I have so far:
> >>> 
> >>> https://github.com/awilliam/mdevctl    
> >> 
> >> While it’s still early, what about :
> >> 
> >> 	mdevctl create-mdev <parent-device> <mdev-type> [<mdev-uuid>]
> >> 
> >> where if the mdev-uuid is missing, you just run uuidgen within the script?
> >> 
> >> I sent a small PR in case you think it makes sense.  
> > 
> > It sounds racy.  If the user doesn't provide the UUID then they need to
> > guess that an mdev device with the same parent and type is theirs.  
> 
> That is true irrespective of the usage, isn’t it? In other words, when you
> invoke `mdevctl create-mdev`, you assert “I own that specific parent/type”.
> At least, that’s how I read the way the script behaves today. Whether you
> invoke uuidgen inside or outside the script does not change that assertion
> (at least with today’s code).

What gives you this impression?  Where is the parent/type ownership
implied?  The intended semantics are "try to create this type of device
under this parent".
 
> >  How do you resolve two instances of this happening in parallel and both
> > coming to the same conclusion which is their device.  If a user wants
> > this sort of headache they can call mdevctl with `uuidgen` but I don't
> > think we should encourage it further.  
> 
> I agree there is a race, but if anything, having a usage where you don’t
> pass the UUID on the command line is a step in the right direction.
> It leaves the door open for the create-mdev script to do smarter things,
> like deferring the allocation of the mdevs to an entity that has slightly
> more knowledge of the global system state than uuidgen.

A user might (likely) require a specific uuid to match their VM
configuration.  I can only think of very niche use cases where a user
doesn't care what uuid they get.

> In other words, in my mind, `mdevctl create-mdev parent type` does not
> imply “this will use uuidgen” but rather, if anything, implies “this will do the
> right thing to prevent the race in the future, even if that’s more complex
> than just calling uuidgen”.

What race are you trying to prevent, uuid collision?

> However, I believe that this means we should reorder the args further.
> I would suggest something like:
> 
> 	mdevctl create-mdev <mdev-type> [<parent-device> [<mdev-uuid>]]
> 
> where

Absolutely not, now you've required mdevctl to implement policy in mdev
placement.  mdevctl follows the unix standard, do one thing and do it
well.  If someone wants to layer placement policy on top of mdevctl,
great, but let's not impose that within mdevctl.

> 1 arg means you let mdevctl choose the parent device for you (future)
>    (e.g. I want a VGPU of this type, I don’t really care where it comes from)
> 2 args mean you want that specific type/parent combination
> 3 args mean you assert you own that device
> 
> That also implies that mdevctl create-mdev should output what it allocated
> so that some higher-level software can tell “OK, that’s the instance I got”.

I don't think we're aligned on what mdevctl is attempting to provide.
Maybe you're describing a layer you'd like to see above mdevctl?
Thanks,

Alex

> > BTW, I've moved the project to https://github.com/mdevctl/mdevctl, the
> > latest commit in the tree above makes that change, I've also updated
> > the description on my repo to point to the new location.  Thanks,  
> 
> Done.
> 
> > 
> > Alex
> > 
> > --
> > libvir-list mailing list
> > libvir-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list  
> 


  reply index

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 23:20 Alex Williamson
2019-05-24 10:11 ` Cornelia Huck
2019-05-24 14:43   ` Alex Williamson
2019-06-07 16:06   ` Halil Pasic
2019-06-11 19:45     ` Cornelia Huck
2019-06-11 20:28       ` Alex Williamson
2019-06-12  7:14         ` Cornelia Huck
2019-06-12 15:54           ` Halil Pasic
2019-06-13 10:02             ` Cornelia Huck
2019-06-12 15:07       ` Halil Pasic
2019-06-13 16:17 ` Christophe de Dinechin
2019-06-13 16:35   ` Alex Williamson
2019-06-14  9:54     ` [libvirt] " Christophe de Dinechin
2019-06-14 14:23       ` Alex Williamson [this message]
2019-06-14 15:06         ` Christophe de Dinechin
2019-06-14 16:04           ` Alex Williamson
2019-06-17 16:03             ` Cornelia Huck
2019-06-17 14:00 ` Daniel P. Berrangé
2019-06-17 14:54   ` Alex Williamson
2019-06-17 15:10     ` Daniel P. Berrangé
2019-06-17 17:05       ` Alex Williamson
2019-06-18  8:44         ` Daniel P. Berrangé
2019-06-18 11:01         ` Cornelia Huck
     [not found]           ` <CALOCmukPWiXiM+mN0hCTvSwfdHy5UdERU8WnvOXiBrMQ9tH3VA@mail.gmail.com>
2019-06-18 22:12             ` Alex Williamson
2019-06-19  7:28               ` Daniel P. Berrangé
2019-06-19  9:46                 ` Cornelia Huck
2019-06-19 18:46                   ` Alex Williamson
2019-06-20  8:24                     ` Daniel P. Berrangé
     [not found]               ` <CALOCmu=6Xmw-_-SVXujCEcgPY2CQiBQKgfUMJ45WnZ_9XORyUw@mail.gmail.com>
2019-06-19  9:57                 ` Cornelia Huck
2019-06-19 19:53                 ` Alex Williamson
2019-06-25 22:52 ` Alex Williamson
2019-06-26  9:58   ` Cornelia Huck
2019-06-26 14:37     ` Alex Williamson
2019-06-27  1:53       ` Alex Williamson
2019-06-27 12:26         ` Cornelia Huck
2019-06-27 15:00           ` Matthew Rosato
2019-06-27 15:38             ` Alex Williamson
2019-06-27 16:13               ` Matthew Rosato
2019-06-27 21:15               ` Alex Williamson
2019-06-28  1:57                 ` Alex Williamson
2019-06-28  9:06                   ` Cornelia Huck
2019-06-28 14:01                     ` Matthew Rosato
2019-06-28 17:05                     ` Alex Williamson
2019-07-01  8:20                       ` Cornelia Huck
2019-07-01 14:40                         ` Alex Williamson
2019-07-01 17:13                           ` Cornelia Huck

Reply instructions:

You may reply publically 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=20190614082328.540a04ea@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=cdupontd@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=eskultet@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=libvir-list@redhat.com \
    --cc=phrdina@redhat.com \
    --cc=sbauza@redhat.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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git