[Bridge] [PATCH] (6/6) bridge: receive path optimization

[Bridge] [PATCH] (6/6) bridge: receive path optimization

[Stephen Hemminger]

This improves the bridge local receive path by avoiding going
through another softirq.  The bridge receive path is already being called 
from a netif_receive_skb() there is no point in going through another
receiveq round trip. 

Recursion is limited because bridge can never be a port of a bridge
so handle_bridge() always returns.

Index: bridge/net/bridge/br_input.c
===================================================================
--- bridge.orig/net/bridge/br_input.c
+++ bridge/net/bridge/br_input.c
@@ -26,7 +26,7 @@ static int br_pass_frame_up_finish(struc
 #ifdef CONFIG_NETFILTER_DEBUG
 	skb->nf_debug = 0;
 #endif
-	netif_rx(skb);
+	netif_receive_skb(skb);
 
 	return 0;
 }

[Bridge] Re: [PATCH] (6/6) bridge: receive path optimization

[David S. Miller]

From: Stephen Hemminger <shemminger@osdl.org>
Date: Thu, 26 May 2005 11:04:25 -0700

> This improves the bridge local receive path by avoiding going
> through another softirq.  The bridge receive path is already being called 
> from a netif_receive_skb() there is no point in going through another
> receiveq round trip. 
> 
> Recursion is limited because bridge can never be a port of a bridge
> so handle_bridge() always returns.

I applied all 6 patches, but this one in particular I'd like
to comment on.

Remember all of those bridge netfilter stack usage issues
we have a few months ago?  This could edge us back into
those problems again.

Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization

[Stephen Hemminger]

On Thu, 26 May 2005 14:46:38 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Thu, 26 May 2005 11:04:25 -0700
> 
> > This improves the bridge local receive path by avoiding going
> > through another softirq.  The bridge receive path is already being called 
> > from a netif_receive_skb() there is no point in going through another
> > receiveq round trip. 
> > 
> > Recursion is limited because bridge can never be a port of a bridge
> > so handle_bridge() always returns.
> 
> I applied all 6 patches, but this one in particular I'd like
> to comment on.
> 
> Remember all of those bridge netfilter stack usage issues
> we have a few months ago?  This could edge us back into
> those problems again.

no, because the br_frame_finish is called after the netfilter
decision:
	netif_receive_skb
	   handle_bridge
               br_handle_frame 
		  br_handle_frame_finish
		     br_pass_frame_up
			br_pass_frame_up_finish
			   netif_receive_skb  <---- change
				(normal receive path)

So the call chain is bounded (ie not related to number of filters)
but slightly longer.

Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization

[David S. Miller]

From: Stephen Hemminger <shemminger@osdl.org>
Date: Thu, 26 May 2005 15:48:57 -0700

> So the call chain is bounded (ie not related to number of filters)
> but slightly longer.

You're right, thanks for the explanation Stephen.

Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization

[Atul Sabharwal]

I have a question about using the 802.1d driver with a switch.  I have a 
managed switch
which connects to the Xscale MAC using a Reverse MII interface.

It seems that the 802.1d bridge puts the interface into promiscuous mode and 
needs multiple
ethernet devices to work with.  Can it work with a single ethernet device 
which is connected
to a BCM5338 ( broadcomm 8 port switch chip ).

I understand that I would have to change the STP configuration component to 
write to the
broadcomm chip.

The chip supports direct memory mapped I/O of BPDU's using polled 
xmite/recieve using
a SPI interface.  Since I use a soft SPI stack, I cannot go faster than 
2MHz. Besides this
is a serial interface.

Suggestion, comments on both choices are highly appreciated.  I am working 
in a custom
enviornment with main objective of detecting loops in a cascade of switches. 
The physical
interconnect of the switches could be linear, tree, star or graph topology.

Also, the spanning tree needs to reconverge when switches are 
connected/disconnected.
Since there are no interrupts from the BCM5338, most of the implementation 
would be
based of polling.  Maybe, a forwarding delay of 5s should work as this is a 
LAN environment.

--
Atul
Linux Engineer 

Re: [Bridge] Re: [PATCH] (6/6) bridge: receive path optimization

[Stephen Hemminger]

On Thu, 26 May 2005 22:57:05 -0700
"Atul Sabharwal" <iamatul@comcast.net> wrote:

> I have a question about using the 802.1d driver with a switch.  I have a 
> managed switch
> which connects to the Xscale MAC using a Reverse MII interface.
> 
> It seems that the 802.1d bridge puts the interface into promiscuous mode and 
> needs multiple
> ethernet devices to work with.  Can it work with a single ethernet device 
> which is connected
> to a BCM5338 ( broadcomm 8 port switch chip ).

Why? what would you gain?

> I understand that I would have to change the STP configuration component to 
> write to the
> broadcomm chip.

You would be better off writing a different driver, the amount of shared
logic would be less than the per hardware logic.