From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guenter Roeck Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets Date: Sun, 22 Mar 2015 19:57:06 -0700 Message-ID: <550F8102.7040701@roeck-us.net> References: <1426870714-3225-1-git-send-email-roopa@cumulusnetworks.com> <20150320.163655.474336751434677390.davem@davemloft.net> <550C92F3.50302@cumulusnetworks.com> <20150320220946.GB31769@lunn.ch> <20150323002215.GA6074@roeck-us.net> <550F6D7D.7030403@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Lunn , roopa , David Miller , sfeldma@gmail.com, jiri@resnulli.us, ronen.arad@intel.com, netdev@vger.kernel.org To: John Fastabend Return-path: Received: from bh-25.webhostbox.net ([208.91.199.152]:53995 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751907AbbCWC5L (ORCPT ); Sun, 22 Mar 2015 22:57:11 -0400 Received: from mailnull by bh-25.webhostbox.net with sa-checked (Exim 4.82) (envelope-from ) id 1YZsY8-001ABm-Lz for netdev@vger.kernel.org; Mon, 23 Mar 2015 02:57:10 +0000 In-Reply-To: <550F6D7D.7030403@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: On 03/22/2015 06:33 PM, John Fastabend wrote: > On 03/22/2015 05:22 PM, Guenter Roeck wrote: >> On Fri, Mar 20, 2015 at 11:09:46PM +0100, Andrew Lunn wrote: >>>> since we have discussed this problem multiple times in switchdev meetings, >>>> the intent of this RFC is to see get the code out and also see if >>>> rocker or any other in-kernel >>>> driver can use it. >>> >>> The Marvell switches in DSA don't have any way to mark packets why >>> they where forwarded towards the host. So i don't see how we could use >>> this feature with these chips. >>> >> >> If we (re-)enable unknown address flooding in the Marvell switch chips, >> we could simply mark all packets received from the switch as "forwarded >> by hardware". Sure, there is no bit in the header, but we would know >> from the chip configuration that the packets were forwarded. >> >> There may be a different problem, though: The driver won't know if >> the packet still needs to be forwarded by the soft bridge, for >> example to a port of a switch on another network interface >> which is part of the same bridge group. >> >> +---+ >> |br0| >> +---+ >> | | >> +--------+ +----+ >> | | >> +---+ +---+ >> |sw0| |sw1| >> +---+ +---+ >> | +---+ | >> +--+ +--+ +--+ >> |p0| |p1| |p2| >> +--+ +--+ +--+ >> >> In this scenarion, sw0 can only know that it forwarded a packet to ports >> on the same switch. It does not know know that the packet needs to be >> forwarded to p2 as well. It would forward the packet from p0 to p1, and >> thus presumably set the hw_fwded bit, but br0 still needs to forward it. >> >> Maybe the check should be "if the packet was HW forwarded, the destination >> is a switch, and the destination is the same switch, don't forward the packet". >> This would be expensive, but on the other side it should not affect too >> many packets. > > I think you might get away with only forwarding if the switch_id is > different then the ingress switch_id if they are the same then drop it That is what I tried to say above with "if ... the destination is the same switch, don't forward the packet". > and assume the hardware already did the forward operation. We could > also add a port setting to turn it on/off if that is important. > > I'm not sure why you would want to forward a packet back on a switch > port of the same switch it was received on. If you want to do this I > think its a special case and can be handled outside the bridge software > via 'tc', 'ovs', 'netfilters', etc. Maybe I missed a case though so > would be glad to hear it if there is one. > I don't. The point I was trying to make is that the patch as written doesn't support the above case, where multiple switches are associated with the same bridge group through different network interfaces. Granted, that may not be a likely case, but it should still be supported. Guenter