dhcpd problem on virtual machines
Ted Lemon
Ted.Lemon at nominum.com
Tue Apr 20 17:09:41 UTC 2010
On Apr 20, 2010, at 8:27 AM, Alex Zeffertt wrote:
> The patch I sent modifies both dhcpd and dhclient so that they always send with
> AF_PACKET. This is a slight performance hit to these processes, but not much.
This isn't why AF_PACKET is used in some cases and not in others. If you use AF_PACKET, routing doesn't work. So your tests will work just fine on your virtual machines, where everything is local subnets, and will also work for cases where you're going through a relay agent (e.g., the initial four-packet handshake), but but will fail to successfully renew leases in most production environments.
> I don't know whether the Linux community have measured the benefit of adding
> support for reception of frames with only the pseudo headers checksummed.
> However, I imagine that for some TCP connections it could be quite a bit. For
> example, if I rsync'd a 10GB home directory from one virtual machine to another
> on the same host, then this flag would save the sender 5 billion 16 bit
> additions and the same for the receiver.
That's one or two seconds of CPU time on a modern Intel processor. And how common is this use case? Normally we use virtualization to set up isolated servers at ISPs. In this situation, the virtual server might get one virtual-to-host dump of the OS install, but after that _all_ of its I/O will be routed on the Internet, meaning it will have to be checksummed anyway. So enabling this feature on such a host gains you a brief performance boost once during the lifetime of the virtual machine, and creates interoperability problems for the whole life of the machine.
If you are creating and destroying virtual machines frequently, that performance boost might be worth the price. But a performance hack that breaks correctness in favor of a minor performance win in some very particular operational circumstances, while it is probably useful to offer as a configuration option, should not be enabled by default.
More information about the dhcp-hackers
mailing list