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:	Fri, 20 Mar 2015 22:53:38 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	John Fastabend <john.r.fastabend@...el.com>,
	"David S. 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 3/20/15, 5:26 PM, Scott Feldman wrote:
> On Fri, Mar 20, 2015 at 4:30 PM, roopa <roopa@...ulusnetworks.com> wrote:
>> On 3/20/15, 3:37 PM, Scott Feldman wrote:
> [cut]
>>> I went back and read the thread just to remind me what the pros/cons
>>> where.  I think the mixed case isn't a concern since this
>>> BR_FLOOD_BCAST check is made on egress to the bridge port.  So only
>>> clear BR_FLOOD_BCAST on hw switch ports (if hw did the flood already
>>> amongst its ports), and leave it set for non-hw-ports.   It seems the
>>> patch should mostly be a clone of how BR_FLOOD is handled.  Is there
>>> more to it?
>> That may work.  But, we have recently moved igmp handling to software in
>> kernel and i was trying to make this work for that case. I am going to try what you
>> suggest  by finding a work around for the igmp case.
> Wait, you lost me on the IGMP comment...that wasn't in your commit
> msg.  Do you mean IGMP snooping?  What are you trying to get to work?
scott, I brought up igmp as an example because we do some selective 
forwarding there.
The point i was trying to make is disabling forwarding on ports is not 
good enough. In some cases, we
do end up making decisions in the switch driver if the packet should be 
forwarded.
  And, that's the reason why having a way to indicate this per packet is 
more flexible.
>
> It's hard to understand the pieces you're considering without example
> implementations.
agreed.

> Can you use rocker or DSA to show example?
yep, let me see what i can do.
I don't plan to add it as a bridge port flag right away,  because 
thinking through this again,
we might hit something else down the lane and we might end up piling up 
flags.
lets see as more use-cases pop up.

--
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