Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: > Anthony Liguori <anthony@xxxxxxxxxxxxx> writes: >> Rusty Russell <rusty@xxxxxxxxxxxxxxx> writes: >> >>> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >>> >>>> Thinking about Sasha's patches, we can reduce ring usage >>>> for virtio net small packets dramatically if we put >>>> virtio net header inline with the data. >>>> This can be done for free in case guest net stack allocated >>>> extra head room for the packet, and I don't see >>>> why would this have any downsides. >>> >>> I've been wanting to do this for the longest time... but... >>> >>>> Even though with my recent patches qemu >>>> no longer requires header to be the first s/g element, >>>> we need a new feature bit to detect this. >>>> A trivial qemu patch will be sent separately. >>> >>> There's a reason I haven't done this. I really, really dislike "my >>> implemention isn't broken" feature bits. We could have an infinite >>> number of them, for each bug in each device. >> >> This is a bug in the specification. >> >> The QEMU implementation pre-dates the specification. All of the actual >> implementations of virtio relied on the semantics of s/g elements and >> still do. > > lguest fix is pending in my queue. lkvm and qemu are broken; lkvm isn't > ever going to be merged, so I'm not sure what its status is? But I'm > determined to fix qemu, and hence my torture patch to make sure this > doesn't creep in again. There are even more implementations out there and I'd wager they all rely on framing. >> What's in the specification really doesn't matter when it doesn't agree >> with all of the existing implementations. >> >> Users use implementations, not specifications. The specification really >> ought to be changed here. > > I'm sorely tempted, except that we're losing a real optimization because > of this :( What optimizations? What Michael is proposing is still achievable with a device feature. Are there other optimizations that can be achieved by changing framing that we can't achieve with feature bits? As I mentioned in another note, bad framing decisions can cause performance issues too... > The specification has long contained the footnote: > > The current qemu device implementations mistakenly insist that > the first descriptor cover the header in these cases exactly, so > a cautious driver should arrange it so. I seem to recall this being a compromise between you and I.. I think I objected strongly to this back when you first wrote the spec and you added this to appease me ;-) Regards, Anthony Liguori > > I'd like to tie this caveat to the PCI capability change, so this note > will move to the appendix with the old PCI layout. > > Cheers, > Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
