From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] virtio-spec: add field for scsi command size
Date: Wed, 19 Jun 2013 14:16:06 +0930 [thread overview]
Message-ID: <87r4fyn1wx.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130617063746.GA5693@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Thu, Jun 13, 2013 at 11:10:47AM +0300, Michael S. Tsirkin wrote:
>> On Thu, Jun 13, 2013 at 11:02:59AM +0300, Michael S. Tsirkin wrote:
>> > On Thu, Jun 13, 2013 at 02:12:22PM +0930, Rusty Russell wrote:
>> > > "Michael S. Tsirkin" <mst@redhat.com> writes:
>> > > > On Thu, Mar 14, 2013 at 04:15:28PM +0100, Paolo Bonzini wrote:
>> > > >> Il 14/03/2013 12:10, Michael S. Tsirkin ha scritto:
>> > > >> > Add field for guest to specify command size for virtio-blk.
>> > > >> >
>> > > >> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> > > >
>> > > > OK, but Rusty usually tweaks wording anyway.
>> > > > Rusty want to apply and make changes Paolo suggested yourself
>> > > > or want me to?
>> > >
>> > > (MST drew my attention back to this)
>> > >
>> > > Please do. And please add a note about this feature: that without it,
>> > > the descriptor layout must be on the right boundaries for historical
>> > > reasons.
>> >
>> > It's there already, isn't it:
>> >
>> > If VIRTIO_BLK_F_SCSI_CMD_SIZE is not negotiated,
>> > This field must reside in a single, separate read-only buffer;
>> > the command length
>> > can be derived from the length of this buffer.
>> >
>>
>> Wait, I think I got it: you actually want to rename this
>> VIRTIO_BLK_F_ANY_SG and have it affect all requests?
>
> Sorry about being dense - could you please clarify?
OK, here's the new section I've written (but not committed!) on Message
Framing:
Message Framing
The original intent of the specification was that message framing
(the particular layout of descriptors) be independent of the
contents of the buffers. For example, a network transmit buffer
consists of a 12 byte header followed by the network packet. This
could be most simply placed in the descriptor table as a 12 byte
output descriptor followed by a 1514 byte output descriptor, but
it could also consist of a single 1526 byte output descriptor in
the case where the header and packet are adjacent, or even three
or more descriptors (possibly with loss of efficiency in that
case).
Regrettably, initial driver implementations used simple layouts,
and devices came to rely on it, despite this specification
wording. It is thus recommended that drivers be conservative in
their assumptions, unless specific device features indicate that
general layout is permitted, such VIRTIO_NET_F_ANY_LAYOUT or
VIRTIO_BLK_F_ANY_LAYOUT. In addition, some implementations may
have large-but-reasonable restrictions on total descriptor size
(such as based on IOV_MAX in the host OS). This has not been a
problem in practice: little sympathy will be given to drivers
which create unreasonably-sized descriptors such as by dividing a
network packet into 1500 single-byte descriptors!
===
Notes:
1) The restrictions are still in place by default.
2) We introduce VIRTIO_NET_F_ANY_LAYOUT and VIRTIO_BLK_F_ANY_LAYOUT
specifically for net and block (note the new names).
3) I note the special case of stupid descriptors.
4) Enjoy our humble pie, don't hide it in a footnote!
If that seems OK, I'll modify the net and block specs appropriately.
Cheers,
Rusty.
next prev parent reply other threads:[~2013-06-19 4:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-14 11:10 [PATCH] virtio-spec: add field for scsi command size Michael S. Tsirkin
2013-03-14 15:15 ` Paolo Bonzini
2013-03-14 17:39 ` Michael S. Tsirkin
2013-03-17 9:26 ` Michael S. Tsirkin
2013-06-13 4:42 ` Rusty Russell
2013-06-13 7:33 ` Michael S. Tsirkin
2013-06-13 8:02 ` Michael S. Tsirkin
2013-06-13 8:10 ` Michael S. Tsirkin
2013-06-17 6:37 ` Michael S. Tsirkin
2013-06-19 4:46 ` Rusty Russell [this message]
2013-06-19 8:24 ` Michael S. Tsirkin
2013-06-19 8:28 ` Paolo Bonzini
2013-06-19 9:21 ` Michael S. Tsirkin
2013-06-20 2:40 ` Rusty Russell
2013-06-20 9:26 ` Paolo Bonzini
2013-06-30 23:47 ` Rusty Russell
2013-07-01 11:57 ` Paolo Bonzini
2013-07-02 6:04 ` Rusty Russell
2013-07-04 7:49 ` Michael S. Tsirkin
2013-07-07 11:31 ` Michael S. Tsirkin
2013-07-08 1:21 ` Rusty Russell
2013-07-08 5:44 ` Michael S. Tsirkin
2013-07-09 1:19 ` Rusty Russell
2013-07-04 7:39 ` Michael S. Tsirkin
2013-07-04 9:05 ` Paolo Bonzini
2013-07-08 4:28 ` Rusty Russell
2013-07-04 7:38 ` Michael S. Tsirkin
2013-06-20 2:45 ` Rusty Russell
2013-03-18 21:47 ` Michael S. Tsirkin
2013-03-19 1:21 ` Rusty Russell
2013-03-19 7:58 ` Michael S. Tsirkin
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=87r4fyn1wx.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=virtualization@lists.linux-foundation.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.