From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Samudrala, Sridhar" Subject: Re: [RFC PATCH net-next] bridge: ability to disable forwarding on a port Date: Mon, 19 Jan 2015 23:09:20 -0800 Message-ID: <54BDFF20.9020909@intel.com> References: <1421479975-62049-1-git-send-email-roopa@cumulusnetworks.com> <54BB7874.90201@cumulusnetworks.com> <54BC1DC5.1000401@cumulusnetworks.com> <54BDF3C7.5010806@cumulusnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "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: roopa , Scott Feldman Return-path: Received: from mga14.intel.com ([192.55.52.115]:36978 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751177AbbATHJ0 (ORCPT ); Tue, 20 Jan 2015 02:09:26 -0500 In-Reply-To: <54BDF3C7.5010806@cumulusnetworks.com> Sender: netdev-owner@vger.kernel.org List-ID: 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? Thanks Sridhar