Re: [virtio-dev] Re: [virtio] [PATCH] ccw: split descriptor/available/used rings

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 17, 2013 at 07:29:45PM +0200, Cornelia Huck wrote:
> On Wed, 16 Oct 2013 10:42:45 +1030
> Rusty Russell <rusty@au1.ibm.com> wrote:
> 
> > Cornelia Huck <cornelia.huck@de.ibm.com> writes:
> > > On Tue, 15 Oct 2013 12:53:00 +1030
> > > Rusty Russell <rusty@au1.ibm.com> wrote:
> > >
> > >> Back to the actual subject of splitting the rings: we've already removed
> > >> the assumption that they will be contiguous from the core of the spec,
> > >> but that does not mean transports need to do the same.
> > >> 
> > >> The effect is to increase the ring size when large contiguous memory
> > >> ranges can't be obtained (eg. hotplug on long-running kernels).
> > >> 
> > >> (PAGESIZE=4096, ALIGN=4096)
> > >> 
> > >> Contiguous Pages        Max Qsz (unsplit)       Max Qsz (split)
> > >> 1                       None                    256
> > >> 2                       128                     512
> > >> 3                       256                     512
> > >> 4                       512                     1024
> > >> 5                       512                     1024
> > >> 6                       512                     1024
> > >> 7                       1024                    1024
> > >> 8                       1024                    2048
> > >> 
> > >> If this doesn't matter to you, it's almost certainly not worth the
> > >> hassle of changing.
> > >
> > > Well, it sounds like a good thing to have, especially since we're
> > > likely to have both long running instances and a lot of hotplugging.
> > 
> > Yes, but Linux is getting much better at moving pages, so it's not the
> > issue it once was.  I'm not sure I'd break compatibility for this alone
> > (though clearly nice to have if you're going to change things anyway).
> 
> Indeed. As we have more going on (like probably endianness), we can
> just throw in this change as well.
> 
> > 
> > > I'd like to extend the communication structure though, like I did in my
> > > alternate proposal. I'll post a v2 without the special command reject
> > > handling.
> > >
> > >> 
> > >> Cheers,
> > >> Rusty.
> > >> PS.  I note that you expose KVM_VIRTIO_CCW_RING_ALIGN through uapi: that
> > >> seems unnecessary?
> > >
> > > virtio-pci exposes its alignment as well.
> > 
> > Yes, but for virtio-pci, it's part of the ABI.  You specify it in 
> > struct vq_info_block, so drivers using this value are suspicious, at
> > least?
> 
> I had wanted to keep alignment open, but the new interface will rely on
> fixed alignments anyway.
> 
> (Though we'll probably want to have a common alignment for all
> transports, won't we?)

There are natural alignment requirements for each part,
such as descriptor being aligned at descriptor size.
They appear in the common text, pls take a look there.

> > 
> > Cheers,
> > Rusty.