Re: [PATCH] bridge: avoid ptype_all packet handling
Am Freitag, 2. März 2007 22:26 schrieb David Miller: The DHCP client should only care about a particular interface's traffic, the one it wants to listen on. Also, a DHCP client should close the socket between address acquisition and renewal. The only interesting events in that period are operstate changes. Stefan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
On Fri, Mar 02, 2007 at 08:22:11PM -0800, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: 03 Mar 2007 03:14:29 +0100 That's pretty common with many x86 server boards because they come with two NICs by default but must people only plug the cable into one. However the distro installers run DHCP on all. Nope, that's not what I've seen them do, instead they run dhcp on interfaces that report a link being present. I've seen otherwise. And that's also bad. It means that when the user moves the machine and happens to plug the Ethernet into the other port network will be a notwork until the configuration is manually changed. Similar when the cable is not plugged in yet at install time. All not good. Allowing low overhead DHCP is useful imho. The main problem with running it always is that it will use more power because it will IFF_UP the interface. But longer term that can be only properly solved by real idle network power management I think. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 28 Feb 2007 17:18:46 -0800 I was measuring bridging/routing performance and noticed this. The current code runs the all packet type handlers before calling the bridge hook. If an application (like some DHCP clients) is using AF_PACKET, this means that each received packet gets run through the Berkeley Packet Filter code in sk_run_filter (slow). I know we closed this out by saying that even though performance sucks, we can't really apply this without breaking things. What would be broken is if the DHCP client isn't specifying a device ifindex when it binds the AF_PACKET socket. That would be an easy way to fix this performance problem at the application level. The DHCP client should only care about a particular interface's traffic, the one it wants to listen on. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
David Miller [EMAIL PROTECTED] writes: And in fact that effectively makes the new socket option pointless, since it doesn't buy us anything since we have to support the old stuff fully anyways. I don't think it's pointless because it would still allow newer DHCP clients to have less impact on other packets when they are active. This can matter when you have a system with multiple interfaces where DHCP doesn't get a address on one. That's pretty common with many x86 server boards because they come with two NICs by default but must people only plug the cable into one. However the distro installers run DHCP on all. When this happens all packets are always forced through ptype_all chains before being rejected by AF_PACKETs device bind, which adds some overhead to them. -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
From: Andi Kleen [EMAIL PROTECTED] Date: 03 Mar 2007 03:14:29 +0100 That's pretty common with many x86 server boards because they come with two NICs by default but must people only plug the cable into one. However the distro installers run DHCP on all. Nope, that's not what I've seen them do, instead they run dhcp on interfaces that report a link being present. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: 03 Mar 2007 03:14:29 +0100 That's pretty common with many x86 server boards because they come with two NICs by default but must people only plug the cable into one. However the distro installers run DHCP on all. Nope, that's not what I've seen them do, instead they run dhcp on interfaces that report a link being present. Actually, It may be even simpler... I start bridge with a script and there was still a dhclient left over running on the original interface. It was an interesting exercise, and I have new tools to help, but still no magic bullet to get up to full line rate. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
On Wed, 2007-28-02 at 23:30 -0800, David Miller wrote: That would be perfect for new applications. But we have to support all the old ones, so we're stuck providing correctly functioning AF_PACKET handling on all devices, sorry. It also breaks all the ingress tc code by making that change. The two scenarios i see in respect to performance are: - run a sniffer and you will see a substantial performance degradation as the pps goes up. There is no rocket science to that. This has nothing to do with bridging and will happen still even if that patch went in. - dont run any tap with the current codepath and you still see the _substantial_ performance drop then we have an opportunity to optimize. Not _by avoiding the code_ as in Stephens patch but by tunning that tap code path. [For example, you should still see a _tiny_ performance degradation if you turned on TC actions on ingress at compile time but had zero policies at run time - but that code path has been reduce to a single compare]. And in fact that effectively makes the new socket option pointless, since it doesn't buy us anything since we have to support the old stuff fully anyways. agreed. I have been tied up elsewhere so havent been following netdev closely: There seem to be complaints of bridging performance going down in recent kernels - or is that someone misconfiguring their drivers? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bridge: avoid ptype_all packet handling
I was measuring bridging/routing performance and noticed this.
The current code runs the all packet type handlers before calling the
bridge hook. If an application (like some DHCP clients) is using AF_PACKET,
this means that each received packet gets run through the Berkeley Packet Filter
code in sk_run_filter (slow).
By moving the bridging hook to run first, the packets flowing through
the bridge get filtered out there. This results in a 14%
improvement in performance, but it does mean that some snooping applications
would miss packets if being used on a bridge. The correct way to see all
packets on a bridge is to set the bridge pseudo-device to promiscuous
mode.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/core/dev.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index cf71614..dc2cda6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1792,6 +1792,10 @@ int netif_receive_skb(struct sk_buff *skb)
rcu_read_lock();
+ if (handle_bridge(skb, pt_prev, ret, orig_dev))
+ goto out;
+
+
#ifdef CONFIG_NET_CLS_ACT
if (skb-tc_verd TC_NCLS) {
skb-tc_verd = CLR_TC_NCLS(skb-tc_verd);
@@ -1826,9 +1830,6 @@ int netif_receive_skb(struct sk_buff *skb)
ncls:
#endif
- if (handle_bridge(skb, pt_prev, ret, orig_dev))
- goto out;
-
type = skb-protocol;
list_for_each_entry_rcu(ptype, ptype_base[ntohs(type)15], list) {
if (ptype-type == type
--
1.4.4.2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
Stephen Hemminger wrote:
I was measuring bridging/routing performance and noticed this.
The current code runs the all packet type handlers before calling the
bridge hook. If an application (like some DHCP clients) is using AF_PACKET,
this means that each received packet gets run through the Berkeley Packet Filter
code in sk_run_filter (slow).
By moving the bridging hook to run first, the packets flowing through
the bridge get filtered out there. This results in a 14%
improvement in performance, but it does mean that some snooping applications
would miss packets if being used on a bridge. The correct way to see all
packets on a bridge is to set the bridge pseudo-device to promiscuous
mode.
Seems it would be better to fix these clients to be more selective as to
where they bind.
This breaks the case where you want to see packets on a particular interface,
not just the entire bridge, right?
Thanks,
Ben
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/core/dev.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index cf71614..dc2cda6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1792,6 +1792,10 @@ int netif_receive_skb(struct sk_buff *skb)
rcu_read_lock();
+ if (handle_bridge(skb, pt_prev, ret, orig_dev))
+ goto out;
+
+
#ifdef CONFIG_NET_CLS_ACT
if (skb-tc_verd TC_NCLS) {
skb-tc_verd = CLR_TC_NCLS(skb-tc_verd);
@@ -1826,9 +1830,6 @@ int netif_receive_skb(struct sk_buff *skb)
ncls:
#endif
- if (handle_bridge(skb, pt_prev, ret, orig_dev))
- goto out;
-
type = skb-protocol;
list_for_each_entry_rcu(ptype, ptype_base[ntohs(type)15], list) {
if (ptype-type == type
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
On Wed, 28 Feb 2007 17:28:09 -0800 Ben Greear [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: I was measuring bridging/routing performance and noticed this. The current code runs the all packet type handlers before calling the bridge hook. If an application (like some DHCP clients) is using AF_PACKET, this means that each received packet gets run through the Berkeley Packet Filter code in sk_run_filter (slow). By moving the bridging hook to run first, the packets flowing through the bridge get filtered out there. This results in a 14% improvement in performance, but it does mean that some snooping applications would miss packets if being used on a bridge. The correct way to see all packets on a bridge is to set the bridge pseudo-device to promiscuous mode. Seems it would be better to fix these clients to be more selective as to where they bind. The problem is any use of BPF is a lose, if it has to be done to all traffic. This breaks the case where you want to see packets on a particular interface, not just the entire bridge, right? It might be possible to use promisc counter to handle this. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
Stephen Hemminger wrote: On Wed, 28 Feb 2007 17:28:09 -0800 Ben Greear [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: I was measuring bridging/routing performance and noticed this. The current code runs the all packet type handlers before calling the bridge hook. If an application (like some DHCP clients) is using AF_PACKET, this means that each received packet gets run through the Berkeley Packet Filter code in sk_run_filter (slow). By moving the bridging hook to run first, the packets flowing through the bridge get filtered out there. This results in a 14% improvement in performance, but it does mean that some snooping applications would miss packets if being used on a bridge. The correct way to see all packets on a bridge is to set the bridge pseudo-device to promiscuous mode. Seems it would be better to fix these clients to be more selective as to where they bind. The problem is any use of BPF is a lose, if it has to be done to all traffic. Right, but couldn't you have the dhcp client bind to eth0, eth7, and br0 (ie, skipping the eth1-6 that comprise the bridge group?) The only difficulty I see is having the client know when new devices come and go, but there are probably ways to know that without keeping a whole lot of state or probing the /proc/net/dev (like my own bloated app does :)) I envision the client args to be something like --skip-devices eth1 eth2 eth3 ... I know you can bind raw packet sockets to individual devices, though I don't know much about BPF, so it's possible I'm wrong... This breaks the case where you want to see packets on a particular interface, not just the entire bridge, right? It might be possible to use promisc counter to handle this. Not really, it's perfectly valid to sniff a port in non-promiscuous mode... Ben - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
Ben Greear wrote: Stephen Hemminger wrote: On Wed, 28 Feb 2007 17:28:09 -0800 Ben Greear [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: I was measuring bridging/routing performance and noticed this. The current code runs the all packet type handlers before calling the bridge hook. If an application (like some DHCP clients) is using AF_PACKET, this means that each received packet gets run through the Berkeley Packet Filter code in sk_run_filter (slow). By moving the bridging hook to run first, the packets flowing through the bridge get filtered out there. This results in a 14% improvement in performance, but it does mean that some snooping applications would miss packets if being used on a bridge. The correct way to see all packets on a bridge is to set the bridge pseudo-device to promiscuous mode. Seems it would be better to fix these clients to be more selective as to where they bind. The problem is any use of BPF is a lose, if it has to be done to all traffic. Right, but couldn't you have the dhcp client bind to eth0, eth7, and br0 (ie, skipping the eth1-6 that comprise the bridge group?) The only difficulty I see is having the client know when new devices come and go, but there are probably ways to know that without keeping a whole lot of state or probing the /proc/net/dev (like my own bloated app does :)) I envision the client args to be something like --skip-devices eth1 eth2 eth3 ... I know you can bind raw packet sockets to individual devices, though I don't know much about BPF, so it's possible I'm wrong... The kernel has to deal with busted applications all the time. And each damn distro and configuration seems to invent it's own new way of doing network configuration. If an normal application has to use something like raw packet filtering, it seems there is a missing API. This breaks the case where you want to see packets on a particular interface, not just the entire bridge, right? It might be possible to use promisc counter to handle this. Not really, it's perfectly valid to sniff a port in non-promiscuous mode... The non-promiscuous mode packets still make it in through the normal receive path. The only packets that don't make up the stack are those that are being bridged. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 28 Feb 2007 23:04:36 -0800 If an normal application has to use something like raw packet filtering, it seems there is a missing API. I'm loosely following this discussion, but Ben mentions DHCP and I remember learning the other month that DHCP uses AF_PACKET and filtering instead of IP RAW sockets because it needs to get the MAC address and RAW sockets don't provide that. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
David Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 28 Feb 2007 23:04:36 -0800 If an normal application has to use something like raw packet filtering, it seems there is a missing API. I'm loosely following this discussion, but Ben mentions DHCP and I remember learning the other month that DHCP uses AF_PACKET and filtering instead of IP RAW sockets because it needs to get the MAC address and RAW sockets don't provide that. sounds like a socket option would help, the data is already there. Then the normal UDP receive path would work. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: avoid ptype_all packet handling
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 28 Feb 2007 23:26:36 -0800 sounds like a socket option would help, the data is already there. Then the normal UDP receive path would work. That would be perfect for new applications. But we have to support all the old ones, so we're stuck providing correctly functioning AF_PACKET handling on all devices, sorry. And in fact that effectively makes the new socket option pointless, since it doesn't buy us anything since we have to support the old stuff fully anyways. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
