From mboxrd@z Thu Jan 1 00:00:00 1970 From: roopa Subject: Re: [RFC PATCH net-next] bridge: ability to disable forwarding on a port Date: Tue, 20 Jan 2015 05:59:04 -0800 Message-ID: <54BE5F28.5090706@cumulusnetworks.com> References: <1421479975-62049-1-git-send-email-roopa@cumulusnetworks.com> <54BB7874.90201@cumulusnetworks.com> <54BC1DC5.1000401@cumulusnetworks.com> <54BDF3C7.5010806@cumulusnetworks.com> <54BDFF20.9020909@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Feldman , "stephen@networkplumber.org" , "David S. Miller" , Jamal Hadi Salim , =?UTF-8?B?SmnFmcOtIFDDrXJrbw==?= , "Arad, Ronen" , Thomas Graf , john fastabend , "vyasevic@redhat.com" , Netdev , Wilson Kok , Andy Gospodarek To: "Samudrala, Sridhar" Return-path: Received: from mail-pa0-f43.google.com ([209.85.220.43]:41792 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752500AbbATN7J (ORCPT ); Tue, 20 Jan 2015 08:59:09 -0500 Received: by mail-pa0-f43.google.com with SMTP id eu11so8533015pac.2 for ; Tue, 20 Jan 2015 05:59:08 -0800 (PST) In-Reply-To: <54BDFF20.9020909@intel.com> Sender: netdev-owner@vger.kernel.org List-ID: On 1/19/15, 11:09 PM, Samudrala, Sridhar wrote: > > On 1/19/2015 10:20 PM, roopa wrote: >> On 1/18/15, 11:37 PM, Scott Feldman wrote: >> >> >>> >>> 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. > > Do you have a switch port netdev that corresponds to CPU port? Or are > they seen on the bridge device? No we dont have a netdev for the CPU port. These show up on the netdev corresponding to the ingress front panel port.