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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Mar 2015 11:08:33 -0700
From:	Scott Feldman <sfeldma@...il.com>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	roopa <roopa@...ulusnetworks.com>,
	John Fastabend <john.fastabend@...il.com>,
	Andrew Lunn <andrew@...n.ch>,
	David Miller <davem@...emloft.net>,
	Jiří Pírko <jiri@...nulli.us>,
	"Arad, Ronen" <ronen.arad@...el.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware
 forwarded packets

On Tue, Mar 24, 2015 at 6:13 AM, Guenter Roeck <linux@...ck-us.net> wrote:
> On 03/23/2015 10:59 PM, Scott Feldman wrote:
>>
>> On Mon, Mar 23, 2015 at 10:12 AM, roopa <roopa@...ulusnetworks.com> 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.

Ya, you're right, turning off BR_FLOOD wouldn't help for those cases.
--
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