RE: [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP

[David Laight <David.Laight@ACULAB.COM>]

From: Dan Williams
...
> > Probably something similar where turn on the broadcast bit and wait
> > for the interface to get configured (2 min timer) and at the expiry
> > decide what is to be done about braodcast bit. If the addresses
> > configured are all IPv6, then eliminate it and if any of them are IPv4
> > then don't change it. In this case no special casing nor snooping is
> > required and this should work for dual-stack scenario as well.
> 
> This does not work for the case where, after configuring, the DHCPv4
> address lease expires and the IPv4 address is removed, and then DHCPv4
> is started again.  Possibly because the DHCP server was gone for a short
> time.  The only way to handle that is to snoop again.
> 
> Reaching for maximum performance is great, but if that is done by
> ignoring/breaking a whole class of normal use-cases, I don't think
> that's reasonable.  It's like saying "gee, I'd love UDP to be faster, so
> I'll remove anything TCP-related in the kernel".
> 
> Also, I don't think the snooping is as bad for performance as you may
> think.  The only relevant issue here is L2 + IPv6-only, and in that case
> it's 4 extra compares (dhcp4_seen, ipv4cnt, lyr3h, and addr_type) for
> the external case.  How much is that really going to slow things down,
> versus breaking a huge part of IPv4 address configuration?

How much performance do you really gain from disabling broadcasts in hardware?
(Unless your network has massive broadcast storms - which are a different problem).
I can imagine it helping a low power device stay idle.

For DHCP you have bigger issues.
All the versions of the dhcp client I've seen use the bpf interface for
receive traffic (even once started) so you get the cost of a clone
of every received packet.

	David