netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Andrew Lunn <andrew@lunn.ch>, roopa <roopa@cumulusnetworks.com>,
	David Miller <davem@davemloft.net>,
	sfeldma@gmail.com, jiri@resnulli.us, ronen.arad@intel.com,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets
Date: Sun, 22 Mar 2015 18:33:49 -0700	[thread overview]
Message-ID: <550F6D7D.7030403@gmail.com> (raw)
In-Reply-To: <20150323002215.GA6074@roeck-us.net>

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
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.

>
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
John Fastabend         Intel Corporation

  reply	other threads:[~2015-03-23  1:34 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20 16:58 [PATCH net-next RFC v2] switchdev: bridge: drop hardware forwarded packets roopa
2015-03-20 17:11 ` John Fastabend
2015-03-20 18:13   ` Scott Feldman
2015-03-20 18:30     ` John Fastabend
2015-03-20 22:06     ` roopa
2015-03-20 22:37       ` Scott Feldman
2015-03-20 23:30         ` roopa
2015-03-21  0:26           ` Scott Feldman
2015-03-21  5:53             ` roopa
2015-03-20 21:03   ` roopa
2015-03-20 21:23     ` John Fastabend
2015-03-20 22:04       ` Andrew Lunn
2015-03-20 23:12       ` roopa
2015-03-20 18:03 ` Scott Feldman
2015-03-20 21:20   ` roopa
2015-03-20 20:36 ` David Miller
2015-03-20 21:36   ` roopa
2015-03-20 22:09     ` Andrew Lunn
2015-03-20 23:43       ` Florian Fainelli
2015-03-23  0:22       ` Guenter Roeck
2015-03-23  1:33         ` John Fastabend [this message]
2015-03-23  2:57           ` Guenter Roeck
2015-03-23  3:18             ` John Fastabend
2015-03-23  3:33               ` Guenter Roeck
2015-03-23 17:12                 ` roopa
2015-03-24  5:59                   ` Scott Feldman
2015-03-24 13:13                     ` Guenter Roeck
2015-03-24 18:08                       ` Scott Feldman
2015-03-24 14:29                     ` Jiri Pirko
2015-03-24 16:01                       ` Guenter Roeck
2015-03-24 17:45                         ` roopa
2015-03-24 17:58                           ` Guenter Roeck
2015-03-24 18:14                             ` Scott Feldman
2015-03-25  3:10                               ` Guenter Roeck
2015-03-25  3:46                               ` Florian Fainelli
2015-03-25  5:06                                 ` Scott Feldman
2015-03-25 17:01                                   ` roopa
2015-03-26  7:44                                     ` Scott Feldman
2015-03-26  8:20                                       ` Jiri Pirko
2015-03-26 14:28                                         ` Scott Feldman
2015-03-26 14:49                                           ` Jiri Pirko
2015-03-27  1:08                                             ` Simon Horman
2015-03-27  6:02                                               ` Jiri Pirko
2015-03-27  6:43                                             ` Scott Feldman
2015-03-27  7:01                                               ` Jiri Pirko
2015-03-27 23:19                                                 ` Scott Feldman
2015-03-30 14:06                                       ` roopa
2015-03-24 18:48                             ` David Christensen
2015-03-24 17:58                         ` Scott Feldman
2015-03-23 17:10           ` roopa
2015-03-23 14:00         ` roopa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550F6D7D.7030403@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=jiri@resnulli.us \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=ronen.arad@intel.com \
    --cc=roopa@cumulusnetworks.com \
    --cc=sfeldma@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).