From: Guenter Roeck <linux@roeck-us.net>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Scott Feldman <sfeldma@gmail.com>,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
Netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Jerome Oufella <jerome.oufella@savoirfairelinux.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kernel@savoirfairelinux.com, Chris Healy <cphealy@gmail.com>
Subject: Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops
Date: Tue, 02 Jun 2015 07:47:14 -0700 [thread overview]
Message-ID: <556DC1F2.1070105@roeck-us.net> (raw)
In-Reply-To: <20150602134252.GT22739@lunn.ch>
On 06/02/2015 06:42 AM, Andrew Lunn wrote:
>> Also, we already have cases where the switch is connected to the CPU with
>> more than one Ethernet port. It is easy to imagine that the user of such
>> a system might want to configure two bridge groups.
>
> Hi Guenter
>
> I think that is orthogonal. Having multiple CPU ports should really
> only be seen as increased throughput with load sharing. It makes no
> different to the basic user use cases. They can all be done with a
> single CPU port, but with less bandwidth.
>
Hi Andrew,
quite possibly, but for my part I usually try not to restrict use cases.
Some people may feel uncomfortable with load sharing and rather use
the separate cpu ports to connect to dedicated external ports on the switch.
Sure, that may reduce overall throughput, but it would provide a cleaner
separation of traffic and guarantee that each of the ports gets its full
bandwidth and is not starved by the other. Yes, I am sure that is all
configurable, but it adds more and more complexity for the user.
Thanks,
Guenter
next prev parent reply other threads:[~2015-06-02 14:47 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 1:27 [RFC 0/9] net: dsa: mv88e6352: add 802.1q VLAN support Vivien Didelot
2015-06-02 1:27 ` [RFC 1/9] net: dsa: add basic support for switchdev obj Vivien Didelot
2015-06-02 1:27 ` [RFC 2/9] net: dsa: add basic support for VLAN operations Vivien Didelot
2015-06-02 6:52 ` Guenter Roeck
2015-06-02 14:42 ` Guenter Roeck
2015-06-03 0:45 ` Vivien Didelot
2015-06-02 1:27 ` [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops Vivien Didelot
2015-06-02 6:50 ` Guenter Roeck
2015-06-02 7:44 ` Scott Feldman
2015-06-02 13:41 ` Guenter Roeck
2015-06-02 13:42 ` Andrew Lunn
2015-06-02 14:47 ` Guenter Roeck [this message]
2015-06-02 22:31 ` nolan
2015-06-03 6:53 ` Scott Feldman
2015-06-03 14:44 ` Guenter Roeck
2015-06-03 18:42 ` Florian Fainelli
2015-06-04 18:22 ` nolan
2015-06-03 1:39 ` Vivien Didelot
2015-06-03 2:17 ` Guenter Roeck
2015-06-03 14:56 ` Vivien Didelot
2015-06-03 15:39 ` Guenter Roeck
2015-06-02 13:05 ` Andrew Lunn
2015-06-02 1:27 ` [RFC 4/9] net: dsa: mv88e6352: add support for VLAN Vivien Didelot
2015-06-02 1:27 ` [RFC 5/9] net: dsa: mv88e6352: disable mirroring Vivien Didelot
2015-06-02 14:16 ` Guenter Roeck
2015-06-02 14:53 ` Andrew Lunn
2015-06-03 1:12 ` Vivien Didelot
2015-06-03 2:27 ` Guenter Roeck
2015-06-02 1:27 ` [RFC 6/9] net: dsa: mv88e6352: allow egress of unknown multicast Vivien Didelot
2015-06-02 14:20 ` Guenter Roeck
2015-06-03 1:52 ` Vivien Didelot
2015-06-09 22:42 ` Vivien Didelot
2015-06-02 1:27 ` [RFC 7/9] net: dsa: mv88e6352: lock CPU port from learning addresses Vivien Didelot
2015-06-02 14:24 ` Guenter Roeck
2015-06-03 1:06 ` Vivien Didelot
2015-06-03 2:24 ` Guenter Roeck
[not found] ` <CAFXsbZo7DAhbUErMfKas_KUtXMHTURgOxwz-GSr=fuAHLWToEQ@mail.gmail.com>
2015-06-03 4:17 ` Guenter Roeck
2015-06-03 20:51 ` Andrew Lunn
2015-06-02 1:27 ` [RFC 8/9] net: dsa: mv88e6352: set port 802.1Q mode to Secure Vivien Didelot
2015-06-02 14:31 ` Guenter Roeck
2015-06-02 23:45 ` Vivien Didelot
2015-06-02 23:28 ` Guenter Roeck
2015-06-02 1:27 ` [RFC 9/9] net: dsa: fix EDSA frame from hwaccel frame Vivien Didelot
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=556DC1F2.1070105@roeck-us.net \
--to=linux@roeck-us.net \
--cc=andrew@lunn.ch \
--cc=cphealy@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jerome.oufella@savoirfairelinux.com \
--cc=jiri@resnulli.us \
--cc=kernel@savoirfairelinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sfeldma@gmail.com \
--cc=vivien.didelot@savoirfairelinux.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).