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

[roopa <roopa@cumulusnetworks.com>]

On 3/20/15, 5:26 PM, Scott Feldman wrote:
> On Fri, Mar 20, 2015 at 4:30 PM, roopa <roopa@cumulusnetworks.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.