From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Cc: Anton Yakovlev <anton.yakovlev@opensynergy.com>,
Mikhail Golubev <Mikhail.Golubev@opensynergy.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>, Takashi Iwai <tiwai@suse.de>,
Mark Brown <broonie@kernel.org>
Subject: Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification
Date: Tue, 12 Nov 2019 17:05:54 +0100 [thread overview]
Message-ID: <20191112160554.GA16008@lophozonia> (raw)
In-Reply-To: <0c5939ad0b330bc4f42d63536340293745dce728.camel@linux.intel.com>
On Tue, Nov 12, 2019 at 02:20:44PM +0000, Liam Girdwood wrote:
> > Other virtio devices rely on the buffer length already provided by
> > virtio
> > for this. For example see the virtio-net control virtqueue
> > (virtio_net_ctrl*), which is extended with new commands from time to
> > time.
> > Most recently, the "receive-side scaling" feature introduces a large
> > structure as payload to virtio_net_ctrl.
> >
>
> Sorry, not following, what does this have to do with combining type and
> size into request_code ? Or are you saying the size is encoded
> elsewhere in the virtio transport data ?
Yes, the buffer size is encoded in the transport data.
[...]
> This would be a good improvement, it's less copying and would likely
> improve user experience, however the buffer ptr still suffers latency
> as it's queued (same for stream positions going the other way).
Right if the queuing overhead is still too large, then I don't think the
current virtqueues can be used.
Thanks,
Jean
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-11-12 16:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 14:43 [virtio-dev] [PATCH] snd: Add virtio sound device specification Mikhail Golubev
2019-10-28 16:05 ` Liam Girdwood
2019-10-29 9:42 ` Anton Yakovlev
2019-10-29 10:14 ` Anton Yakovlev
[not found] ` <20191029121810.GB5253@sirena.co.uk>
2019-10-29 13:16 ` Anton Yakovlev
[not found] ` <20191030121137.GC6693@sirena.co.uk>
2019-11-01 13:37 ` Anton Yakovlev
[not found] ` <20191111193903.GE4264@sirena.co.uk>
2019-11-13 12:01 ` Anton Yakovlev
[not found] ` <20191114212940.GC4664@sirena.co.uk>
2019-11-19 9:26 ` Anton Yakovlev
2019-11-11 15:20 ` Liam Girdwood
2019-11-12 11:09 ` Jean-Philippe Brucker
2019-11-12 14:20 ` Liam Girdwood
2019-11-12 16:05 ` Jean-Philippe Brucker [this message]
2019-11-12 18:02 ` Liam Girdwood
2019-11-12 18:47 ` Matti Moell
2019-11-19 15:23 ` Liam Girdwood
2019-11-13 9:44 ` Anton Yakovlev
2019-11-19 16:09 ` Liam Girdwood
2019-11-20 14:24 ` Anton Yakovlev
2019-11-21 9:04 ` Gerd Hoffmann
2019-11-21 12:57 ` Anton Yakovlev
2019-11-22 7:19 ` Gerd Hoffmann
2019-11-22 13:46 ` Anton Yakovlev
2019-11-25 9:31 ` Gerd Hoffmann
2019-12-02 13:06 ` Anton Yakovlev
2019-12-03 9:00 ` Gerd Hoffmann
2019-12-04 11:15 ` Anton Yakovlev
2019-12-04 12:52 ` Gerd Hoffmann
2019-12-05 12:06 ` Anton Yakovlev
2019-12-06 8:31 ` Gerd Hoffmann
[not found] ` <20191122123521.GB6849@sirena.org.uk>
2019-11-22 14:06 ` Anton Yakovlev
[not found] ` <D68AC0D0-851B-4F87-BE0E-F49527B83E24@redhat.com>
2019-11-28 11:42 ` Gerd Hoffmann
2019-12-02 13:28 ` Anton Yakovlev
[not found] ` <20191128121920.GB4210@sirena.org.uk>
2019-12-02 13:30 ` Anton Yakovlev
[not found] ` <20191202135519.GF1998@sirena.org.uk>
2019-12-04 8:04 ` Anton Yakovlev
2019-11-25 16:50 ` Liam Girdwood
2019-11-13 7:54 ` Anton Yakovlev
2019-11-12 12:45 ` Anton Yakovlev
2019-11-12 15:16 ` Liam Girdwood
2019-11-13 9:05 ` Anton Yakovlev
2019-11-19 15:49 ` Liam Girdwood
2019-11-20 9:32 ` Gerd Hoffmann
[not found] ` <20191028192952.GI5015@sirena.co.uk>
2019-10-29 10:46 ` Anton Yakovlev
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=20191112160554.GA16008@lophozonia \
--to=jean-philippe@linaro.org \
--cc=Mikhail.Golubev@opensynergy.com \
--cc=anton.yakovlev@opensynergy.com \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=tiwai@suse.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox