dhcpd problem on virtual machines

[Alex Zeffertt]

Ted Lemon wrote:
> 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'm not sure I understand why the DHCP server would not be on the same LAN as 
the client during lease renewal when it has to be on the same LAN for the 
discover.  However, whatever the explanation, if you need routing for the 
renewal packets then, you're right, using AF_PACKET won't work.  I guess that 
means we need a different solution :-(.

> 
>> 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.
> 

Actually, the TCP and UDP packets may never have to be checksummed by the CPU. 
There are two cases.  In case 1 the packet is going to another VM on the same 
host, only the pseudo header is checksummed, and the PARTIAL flag is set on 
receive indicating there's no need to verify.  In case 2 the packet is going out 
on the wire.  In this case the CPU only has to complete the checksum if the NIC 
doesn't support tx checksum offloading.  If it does support tx checksum 
offloading then the driver indicates to the NIC the start and end of the UDP or 
TCP packet and the location of the partial checksum, and the NIC completes the 
checksum.

I think it would be difficult to convince the Linux developers to remove support 
for reception of partially checksummed packets.  My gut instinct is that they 
will not be prepared to sacrifice performance to benefit applications doing 
TCP/IP in userspace.  However, it might be worth bringing this up to see if 
there is an overlooked solution that doesn't sacrifice performance, or require 
applications like dhcp-isc to be virtualisation-aware.

Regards,

Alex