On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote: > For those not following closely: We already have a method for the > guest to accept or reject features. Our problem is that the guest > is already accepting the CSUM feature: but one critical userspace > app (dhcp-client) can't actually handle it due to a bug.
Can't we just get dhcp-client client fixed upstream and let the distro's update in a couple of months? > The proposal is to add another mechanism, whereby the host doesn't > advertise CSUM, but advertises a new CSUM2 feature. The driver > doesn't accept this by default: then guest userspace says "hey, I > *really can* handle CSUM". This would have to be done dby resetting > the device in the ethtool callback (that's how we renegotiate > features). And guests need a special virtio hack in their init > scripts. If guest can have modified scripts for virtio and what not, they can have a fixed dhcp-client. > This leaves the small number of current users without CSUM (and > hence GSO etc). Yet they might not use dhcp with bridging anyway. I think for now that's fine, it's a performance hit that people can tweak away explicitly without having to add something like a CSUM2 feature. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
