OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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?)

> 
> Cheers,
> Rusty.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]