Subject: Re: [RFC PATCH net-next] bridge: ability to disable forwarding on a port

From: roopa <[email-masked]>
Date: Mon, 19 Jan 2015 22:20:55 -0800

On 1/18/15, 11:37 PM, Scott Feldman wrote:

<snip..>
>
> Not sure. I don't know the use case, but I think I might have heard that
> there could be a case
>   where a switch port could be bridged with a vm's port running on the
> switch. (?)
>>
>> Ignoring the above usecase for a bit. And thinking through this again, It
>> appears that this check should
>> be only on the ingress port, no ?
>>
>> If the ingress bridge port is an offloaded port, don't flood or forward
>> because hardware has already done it.
>> And this is best done with the offload feature flag on the bridge port.
> That's assuming hardware did the flood.  Maybe your other option to
> mark the skb if already flooded by hw is best.  That's enough info for
> the bridge driver to make a decision to flood or not to the other
> ports, and it's an implementation decision for the driver/device to do
> the flood offload, if desired, and mark the skb if it did.

Still thinking we can just use the offload feature flag here. How about  
avoid forwarding only if both src and dst ports have
forwarding offloaded/accelerated by a switch asic  ?. That should cover 
all cases.
>
> Btw, you're still saying flood or forward, but in my mind we're
> talking about flood only: flood of unknown unicast or flood of
> bcast/mcast pkts.  Forwarding would be for known-unicast pkts, which
> should even involve the bridge driver since that forwarding is
> offloaded to the device.

I was also taking into account pkts copied to the CPU due to an acl rule such as log.
These unicast pkts can come to cpu even if it is already forwarded in hw.

Thanks,
Roopa