[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-hackers
Subject:    Re: dhcpd problem on virtual machines
From:       Ted Lemon <Ted.Lemon () nominum ! com>
Date:       2010-04-21 14:45:50
Message-ID: 75F9E837-0AD4-4669-9E67-EF4453922661 () nominum ! com
[Download RAW message or body]

On Apr 21, 2010, at 2:27 AM, Alex Zeffertt wrote:
> 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.

There is in fact always a DHCP server or relay agent connected to any network served \
by DHCP.   If the DHCP server is not on the local wire, the DHCP relay agent acts as \
an intermediary until the client gets an IP address.   After the client has an IP \
address, though, the DHCP relay agent is no longer needed, and at that point renewals \
are processed using unicast communication to the DHCP server, which is routed if the \
DHCP server is off-network.

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

Yes.

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

I'm not proposing that they remove support for this performance hack.   I'm proposing \
that since the behavior of the kernel is inconsistent when the hack is enabled, it \
should not be enabled by default.   As long as there's a sysctl to enable it, anyone \
who benefits from this performance hack can easily enable it on system startup, but \
since it will require a positive action to enable, it will no longer violate the \
principle of least surprise.

The trick to debating with Linux kernel people is to push gently, and never be \
offended when they call you an idiot.   If you can pull that off, and be persistent, \
in the long run chances are the right thing will happen.   (I learned this the hard \
way, of course... :')

_______________________________________________
dhcp-hackers mailing list
dhcp-hackers@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-hackers


[prev in list] [next in list] [prev in thread] [next in thread]