All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] virtio-spec: add field for scsi command size
Date: Thu, 4 Jul 2013 10:49:43 +0300	[thread overview]
Message-ID: <20130704074942.GA4777@redhat.com> (raw)
In-Reply-To: <87txkdfqg6.fsf@rustcorp.com.au>

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> > Il 01/07/2013 01:47, Rusty Russell ha scritto:
> >> > > 
> >> > > Mainly because I'm not sure that *all* devices are now safe.  Are they?
> >> >
> >> > virtio-scsi's implementation in QEMU is not safe (been delaying that for
> >> > too long, sorry), but the spec is safe.
> >> 
> >> Then if we added a transport feature, we couldn't use it :(
> >
> > Transport feature bits are still negotiated per device though.
> > virtio-scsi devices in QEMU would not negotiate that feature.
> 
> That's a good point; I tend to think of them as tied to the transport
> but there's nothing specifying that, nor any implementation requiring
> it.
> 
> OK, so VIRTIO_F_ANY_LAYOUT it is?
> 
> Cheers,
> Rusty.
> 
> 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 using VIRTIO_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 dividing a network packet into 1500
> single-byte descriptors!

That's fine with me too.
So which bit are we using for this?
I'd like to rebase to latest bits and merge the optimization for 3.11.

-- 
MST

  reply	other threads:[~2013-07-04  7:49 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
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 [this message]
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=20130704074942.GA4777@redhat.com \
    --to=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --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.