dhcpd problem on virtual machines
Alex Zeffertt
alex.zeffertt at eu.citrix.com
Tue Apr 20 15:27:40 UTC 2010
Ted Lemon wrote:
> On Apr 20, 2010, at 2:34 AM, Alex Zeffertt wrote:
>> However, fixing this in dhcpd/dhclient is much more straight forward. We simply
>> need to acknowledge that if the sender uses AF_INET then so should the receiver.
>> Or alternatively, if the receiver uses AF_PACKET then so should the sender.
>
> I don't disagree with your basic conclusion here, but in what sense is this
> "easy"? How would the DHCP client or DHCP server know? I mean, you could add a
> command-line flag that says "don't checksum," but this is problematic if one
> server is virtual and another isn't, and also the user has to know to use the
> flag, the reason for which most end-users would find peculiar and unexpected.
>
> Has anybody actually measured the benefit of this hack? Is there a use case
> for it? It sounds a lot like a case of premature optimization. It seems to me
> that it would be better to have a kernel flag, off by default, that enables this
> feature. That way the people for whom this optimization is valuable would turn
> it on, and you could inform them in the documentation that they might need to
> also hack the DHCP server or client.
>
Hi Ted,
Thanks for your email. I guess I characterised the requirement wrongly. What I
should have said is that if the sender uses AF_INET then the receiver must also
use AF_INET. However, if the sender uses AF_PACKET and builds the header in
userspace then the receiver can use either socket type.
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.
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.
Regards,
Alex
More information about the dhcp-hackers
mailing list