Thread (51 messages) 51 messages, 11 authors, 2015-03-30

Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets

From: Scott Feldman <hidden>
Date: 2015-03-24 18:08:50

On Tue, Mar 24, 2015 at 6:13 AM, Guenter Roeck [off-list ref] wrote:
On 03/23/2015 10:59 PM, Scott Feldman wrote:
quoted
On Mon, Mar 23, 2015 at 10:12 AM, roopa [off-list ref] wrote:
quoted
On 3/22/15, 8:33 PM, Guenter Roeck wrote:
quoted
[ ... ]
quoted
quoted
yep, so my first RFC listed three ways to do this,
1) flag on the bridge port
2) check if the port being forwarded to is a switch port, using
             - the offload flag
             - the parent id (as john fastabend pointed out)
3) A per packet flag which switch driver sets indicating that the packet
is
hw forwarded.
     This is because we have run into cases where we want to move to
software
forwarding
     of certain packets like igmp reports.  (I will get some more details
on
the particular igmp problem).
     In such case, hardware punts the igmp packet to cpu and cpu will do
the
forwarding.
     I think we may hit more cases like this in the future.

my RFC v1 was based on 1). RFC v2 was based on 3) above.

But, for now, agree that we can just support the more common case using
2).
And, we can move to 3) in the future if needed.

Roopa, I think it may be possible to do this without any changes to
the bridge code or switchdev code by dropping duplicate pkts in the
swdev driver itself.  The skb is marked with skb_iif set to ifindex of
ingress port, so when the driver goes to egress a pkt on the port, if
the skb_iif is one of the other device ports, we can assume the device
did the fwd already so we can drop the duplicate pkt.  Below is the
change to rocker.  The driver can get as fancy as it wants in its test
to drop or not.  This solution works for mixed offload and
non-offloaded ports in a bridge, or ports from different offload
devices in the same bridge.

Yes, the bridge is spending overhead to clone pkts to flood to its
ports.  IGMP snooping mitigates this for mcast.  BR_FLOOD can be
turned off on the bridge ports to mitigate this for unknown unicast
floods.  So what's left is bcasts.
You would still want the soft bridge code to flood from non-switch ports
to switch ports and vice versa, as well as across multiple switches.
So I am not entirely sure I understand how turning off BR_FLOOD would help.
Ya, you're right, turning off BR_FLOOD wouldn't help for those cases.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help