lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 8 Apr 2015 18:08:14 -0700 From: Mahesh Bandewar <maheshb@...gle.com> To: David Laight <David.Laight@...lab.com> Cc: Dan Williams <dcbw@...hat.com>, linux-netdev <netdev@...r.kernel.org>, "jbenc@...hat.com" <jbenc@...hat.com> Subject: Re: [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP On Wed, Apr 8, 2015 at 2:37 AM, David Laight <David.Laight@...lab.com> wrote: > 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. > IPvlan is a virtual driver and is enabling / disabling broadcast on these virtual links. So N virtual links mean N*clone and that's the cost. > 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 > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists