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

From: Guenter Roeck <[email-masked]>
Date: Tue, 24 Mar 2015 06:13:39 -0700

On 03/23/2015 10:59 PM, Scott Feldman wrote:
> On Mon, Mar 23, 2015 at 10:12 AM, roopa <[email-masked]> wrote:
>> On 3/22/15, 8:33 PM, Guenter Roeck wrote:
>>>
[ ... ]
>>
>> 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.

Thanks,
Guenter