On Thu, Oct 17, 2013 at 07:29:45PM +0200, Cornelia Huck wrote:
> On Wed, 16 Oct 2013 10:42:45 +1030
> Rusty Russell <> wrote:
>
> > Cornelia Huck <> writes:
> > > On Tue, 15 Oct 2013 12:53:00 +1030
> > > Rusty Russell <> 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.
