All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Sepp <dmitry.sepp@opensynergy.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Keiichi Watanabe" <keiichiw@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	virtio-dev@lists.oasis-open.org,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"David Stevens" <stevensd@chromium.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Date: Mon, 9 Dec 2019 12:38:20 +0100	[thread overview]
Message-ID: <1970145.L65FEUb58e@os-lin-dmo> (raw)
In-Reply-To: <20191209104615.ulct6p34cn7ypvrz@sirius.home.kraxel.org>

Hi,

On Montag, 9. Dezember 2019 11:46:15 CET Gerd Hoffmann wrote:
>   Hi,
> 
> > > For (1) you'll simply do a QUEUE_BUFFER.  The command carries references
> > > to the buffer pages.  No resource management needed.
> > > 
> > > For (2) you'll have RESOURCE_CREATE + RESOURCE_DESTROY + QUEUE_RESOURCE,
> > > where RESOURCE_CREATE passes the scatter list of buffer pages to the
> > > host and QUEUE_RESOURCE will carry just the resource id.
> > > 
> > > For (3) you'll have RESOURCE_IMPORT + RESOURCE_DESTROY + QUEUE_RESOURCE.
> > 
> > Thanks for the clarification.
> > On second thought, however, I'm wondering if we should keep all
> > RESOURCE controls.
> > This should be an option (4).
> 
> Well, that's actually (2), aka "we use RESOURCE_* commands to manage
> resources".  With the commands in the latest draft that would be:
> 
>   (1) RESOURCE_CREATE
>   (2) RESOURCE_ATTACH_BACKING
>   (3) RESOURCE_QUEUE (resource can be used multiple times here)
>   (4) RESOURCE_DETACH_BACKING
>   (5) RESOURCE_DESTROY
> 
> I'm not sure we need the separate *_BACKING commands.  I think we could
> also have RESOURCE_CREATE pass the buffer pages scatter list instead.
> 
> Why it is done this way?  Just because the design was copied from
> virtio-gpu?  Or is there some specific reason?

Yes, the design was just derived from virtio-gpu at early stages.

I do agree we should merge the two steps.

> 
> cheers,
>   Gerd



---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Sepp <dmitry.sepp@opensynergy.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Keiichi Watanabe" <keiichiw@chromium.org>,
	"Enrico Granata" <egranata@google.com>,
	virtio-dev@lists.oasis-open.org,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Alexandre Courbot" <acourbot@chromium.org>,
	"Alex Lau" <alexlau@chromium.org>,
	"Dylan Reid" <dgreid@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Pawel Osciak" <posciak@chromium.org>,
	"David Stevens" <stevensd@chromium.org>,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Date: Mon, 9 Dec 2019 12:38:20 +0100	[thread overview]
Message-ID: <1970145.L65FEUb58e@os-lin-dmo> (raw)
In-Reply-To: <20191209104615.ulct6p34cn7ypvrz@sirius.home.kraxel.org>

Hi,

On Montag, 9. Dezember 2019 11:46:15 CET Gerd Hoffmann wrote:
>   Hi,
> 
> > > For (1) you'll simply do a QUEUE_BUFFER.  The command carries references
> > > to the buffer pages.  No resource management needed.
> > > 
> > > For (2) you'll have RESOURCE_CREATE + RESOURCE_DESTROY + QUEUE_RESOURCE,
> > > where RESOURCE_CREATE passes the scatter list of buffer pages to the
> > > host and QUEUE_RESOURCE will carry just the resource id.
> > > 
> > > For (3) you'll have RESOURCE_IMPORT + RESOURCE_DESTROY + QUEUE_RESOURCE.
> > 
> > Thanks for the clarification.
> > On second thought, however, I'm wondering if we should keep all
> > RESOURCE controls.
> > This should be an option (4).
> 
> Well, that's actually (2), aka "we use RESOURCE_* commands to manage
> resources".  With the commands in the latest draft that would be:
> 
>   (1) RESOURCE_CREATE
>   (2) RESOURCE_ATTACH_BACKING
>   (3) RESOURCE_QUEUE (resource can be used multiple times here)
>   (4) RESOURCE_DETACH_BACKING
>   (5) RESOURCE_DESTROY
> 
> I'm not sure we need the separate *_BACKING commands.  I think we could
> also have RESOURCE_CREATE pass the buffer pages scatter list instead.
> 
> Why it is done this way?  Just because the design was copied from
> virtio-gpu?  Or is there some specific reason?

Yes, the design was just derived from virtio-gpu at early stages.

I do agree we should merge the two steps.

> 
> cheers,
>   Gerd



  reply	other threads:[~2019-12-09 11:38 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 19:19 [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification Dmitry Sepp
2019-11-05 19:19 ` Dmitry Sepp
2019-11-07  9:56 ` [virtio-dev] " Gerd Hoffmann
2019-11-07  9:56   ` Gerd Hoffmann
2019-11-07 13:09   ` Dmitry Sepp
2019-11-07 13:09     ` Dmitry Sepp
2019-11-08  7:49     ` Gerd Hoffmann
2019-11-08  7:49       ` Gerd Hoffmann
2019-11-08  7:58       ` Tomasz Figa
2019-11-08  7:58         ` Tomasz Figa
2019-11-08  9:51       ` Dmitry Sepp
2019-11-08  9:51         ` Dmitry Sepp
2019-11-08  7:50     ` Tomasz Figa
2019-11-08  7:50       ` Tomasz Figa
2019-11-08  9:05       ` Gerd Hoffmann
2019-11-08  9:05         ` Gerd Hoffmann
2019-11-08  9:28         ` Keiichi Watanabe
2019-11-08  9:28           ` Keiichi Watanabe
2019-11-20 11:29           ` Gerd Hoffmann
2019-11-20 11:29             ` Gerd Hoffmann
2019-11-21 10:54             ` Dmitry Sepp
2019-11-21 10:54               ` Dmitry Sepp
2019-12-04  7:48               ` Keiichi Watanabe
2019-12-04  7:48                 ` Keiichi Watanabe
2019-12-04  9:16                 ` Gerd Hoffmann
2019-12-04  9:16                   ` Gerd Hoffmann
2019-12-04 19:11                   ` Enrico Granata
2019-12-04 19:11                     ` Enrico Granata
2019-12-05  8:21                     ` Keiichi Watanabe
2019-12-05  8:21                       ` Keiichi Watanabe
2019-12-06  7:32                       ` Gerd Hoffmann
2019-12-06  7:32                         ` Gerd Hoffmann
2019-12-06 12:30                         ` Keiichi Watanabe
2019-12-06 12:30                           ` Keiichi Watanabe
2019-12-06 15:50                           ` Enrico Granata
2019-12-06 15:50                             ` Enrico Granata
2019-12-09 13:43                             ` Keiichi Watanabe
2019-12-09 13:43                               ` Keiichi Watanabe
2019-12-09 10:46                           ` Gerd Hoffmann
2019-12-09 10:46                             ` Gerd Hoffmann
2019-12-09 11:38                             ` Dmitry Sepp [this message]
2019-12-09 11:38                               ` Dmitry Sepp
2019-12-09 13:17                               ` Keiichi Watanabe
2019-12-09 13:17                                 ` Keiichi Watanabe
2019-12-09 14:19                   ` Dmitry Sepp
2019-12-09 14:19                     ` Dmitry Sepp
2019-12-09 21:12                     ` Enrico Granata
2019-12-10 13:16                       ` Dmitry Sepp
2019-12-10 13:16                         ` Dmitry Sepp
2019-12-12  5:39                         ` Keiichi Watanabe
2019-12-12  5:39                           ` Keiichi Watanabe
2019-12-12 10:34                           ` Dmitry Sepp
2019-12-12 10:34                             ` Dmitry Sepp
2019-12-13 14:20                             ` Keiichi Watanabe
2019-12-13 14:20                               ` Keiichi Watanabe
2019-12-13 16:31                               ` Keiichi Watanabe
2019-12-13 16:31                                 ` Keiichi Watanabe
2019-12-20 14:24                                 ` Dmitry Sepp
2019-12-20 14:24                                   ` Dmitry Sepp
2019-12-20 15:01                                   ` Keiichi Watanabe
2019-12-20 15:01                                     ` Keiichi Watanabe
2019-12-13 14:58                     ` Christophe de Dinechin
2019-12-13 14:58                       ` Christophe de Dinechin
2019-12-16  8:09                   ` Tomasz Figa
2019-12-16  8:09                     ` Tomasz Figa
2019-12-16 10:32                     ` Gerd Hoffmann
2019-12-16 10:32                       ` Gerd Hoffmann
2019-12-17 13:15                       ` Tomasz Figa
2019-12-17 13:15                         ` Tomasz Figa
2019-12-17 13:39                         ` Gerd Hoffmann
2019-12-17 13:39                           ` Gerd Hoffmann
2019-12-17 14:09                           ` Keiichi Watanabe
2019-12-17 14:09                             ` Keiichi Watanabe
2019-12-17 16:13                             ` Dmitry Sepp
2019-12-17 16:13                               ` Dmitry Sepp
2019-12-18  6:43                               ` Gerd Hoffmann
2019-12-18  6:43                                 ` Gerd Hoffmann

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=1970145.L65FEUb58e@os-lin-dmo \
    --to=dmitry.sepp@opensynergy.com \
    --cc=acourbot@chromium.org \
    --cc=alexlau@chromium.org \
    --cc=daniel@ffwll.ch \
    --cc=dgreid@chromium.org \
    --cc=egranata@google.com \
    --cc=hverkuil@xs4all.nl \
    --cc=keiichiw@chromium.org \
    --cc=kraxel@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=posciak@chromium.org \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=virtio-dev@lists.oasis-open.org \
    /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.