From: Jamal Hadi Salim <jhs@mojatatu•com>
To: Felix Fietkau <nbd@openwrt•org>,
Florian Fainelli <f.fainelli@gmail•com>,
Neil Horman <nhorman@tuxdriver•com>
Cc: John Fastabend <john.r.fastabend@intel•com>,
netdev <netdev@vger•kernel.org>,
David Miller <davem@davemloft•net>,
Sascha Hauer <s.hauer@pengutronix•de>,
John Crispin <blogic@openwrt•org>,
Jonas Gorski <jogo@openwrt•org>, Gary Thomas <gary@mlbassoc•com>,
Vlad Yasevich <vyasevic@redhat•com>,
Stephen Hemminger <stephen@networkplumber•org>
Subject: Re: [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet switch configuration API
Date: Sun, 27 Oct 2013 13:19:02 -0400 [thread overview]
Message-ID: <526D4B06.8040505@mojatatu.com> (raw)
In-Reply-To: <526A6BB3.7050507@openwrt.org>
On 10/25/13 09:01, Felix Fietkau wrote:
> On 2013-10-25 1:43 PM, Jamal Hadi Salim wrote:
> I think it's common for the switch to have a global MAC address, not a
> per-port one.
Ok, I see. Real cheep.
> 'won't pass up the tag'? The switch is treated in pretty much the same
> way as a normal managed standalone switch (you know, one you can buy in
> a shop and plug your Ethernet cable into).
> You simply tell it, which VLANs to put on which ports, and make the
> ports tagged or untagged.
> The link between the switch and the CPU is not really special, for the
> switch it's just another port. This way of configuring works with pretty
> much all switches that we're using.
So does it get its own MAC address? Other than flooding broadcasts,
how does one end up sending packets to the cpu?
> Yes, some switches have them, and they can be useful when dealing with
> multiple VLANs.
Very nice. So we go from one extreme of cheep to sophisticated ;->
I think the only way you can achieve multiple tables on the bridge
is by creating multiple bridges.
> No, because the connection between the CPU and the switch is handled by
> a normal Ethernet MAC. The Ethernet chip doesn't care if there's a
> switch connected to it, or a regular PHY.
> It's just a normal MII connection, nothing more.
>
[..]
>
> Right, the netdev that owns the PHY is a normal Ethernet MAC, running
> any normal Linux Ethernet driver.
>
[..]
> I remain absolutely unconvinced that this will make the end result
> better. Right now, these switches act like separate devices, because
> aside from the fact that they're put on the same board with other
> components, they pretty much *are* separate devices.
>
> You seem to insist on treating it as a kind of port multiplexer + bridge
> accelerator instead of a mostly standalone switch.
>
Yes, the above is the point i was making.
I apologize for sounding like a broken record, but to just re-iterate:
there are, if i recall correctly, several drivers in the kernel
which are challenged as such (with single entry point into the CPU)
which expose multiple netdevs with the driver acting as mux point.
> This may work for some devices, but on others this simply a model that
> the hardware wasn't designed for.
I agree. But what i just described above is not new. A lot of embedded
multiport NICs tend to be handicapped in exactly the same way.
> Sure, we could try to cram in all
> those special cases, extra options, and hack through the layers where
> they're in the way. If *all* you care about is being able to reuse the
> existing interfaces, that might even seem like a good idea.
>
I do care a lot about using existing interfaces ;-> Great usability
for someone to run a tool that has been around for 20 years and it
works. If i can just reuse my scripts without having to invent
new ones etc etc.
> On the other hand, I've pointed out quite a few examples where the model
> of trying to cram it into the bridge API is just a bad fit in general.
>
Sorry Felix, nothing you described is insurmountable.
The challenge here is non-technical:
You already have code that has been proven and is deployed for what
appears to be sometime now.
I totally empathize.
cheers,
jamal
next prev parent reply other threads:[~2013-10-27 17:19 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-22 18:23 [PATCH 0/4 net-next] net: phy: add Generic Netlink switch configuration API Florian Fainelli
2013-10-22 18:23 ` [PATCH 1/4 net-next] net: phy: add Generic Netlink Ethernet " Florian Fainelli
2013-10-22 19:22 ` Dan Williams
2013-10-22 19:32 ` Florian Fainelli
2013-10-22 19:47 ` David Miller
[not found] ` <1382477150.19269.69.camel@dcbw.foobar.com>
2013-10-22 21:22 ` David Miller
2013-10-22 19:46 ` David Miller
2013-10-22 19:53 ` John Fastabend
2013-10-22 19:59 ` Florian Fainelli
2013-10-22 20:25 ` Neil Horman
2013-10-22 22:09 ` Florian Fainelli
2013-10-23 11:34 ` Neil Horman
2013-10-23 11:47 ` Jamal Hadi Salim
2013-10-23 12:04 ` Felix Fietkau
2013-10-23 12:53 ` Jamal Hadi Salim
2013-10-23 13:31 ` Felix Fietkau
2013-10-23 14:09 ` Jamal Hadi Salim
2013-10-23 14:32 ` Felix Fietkau
2013-10-25 11:43 ` Jamal Hadi Salim
2013-10-25 13:01 ` Felix Fietkau
2013-10-27 17:19 ` Jamal Hadi Salim [this message]
2013-10-27 18:14 ` Florian Fainelli
2013-10-28 22:29 ` Jamal Hadi Salim
2013-10-27 19:51 ` Felix Fietkau
2013-10-28 22:53 ` Jamal Hadi Salim
2013-10-29 9:34 ` Felix Fietkau
2013-10-30 11:45 ` Jamal Hadi Salim
2013-10-30 12:53 ` Felix Fietkau
2013-10-30 17:27 ` Lennert Buytenhek
2013-10-30 17:34 ` Lennert Buytenhek
2013-10-30 17:56 ` John Fastabend
2013-10-30 17:56 ` John Fastabend
2013-10-30 19:47 ` Felix Fietkau
2013-12-07 1:45 ` Florian Fainelli
2013-10-29 23:12 ` Maxime Bizon
2013-10-30 11:50 ` Jamal Hadi Salim
2013-10-30 11:58 ` Felix Fietkau
2013-10-30 14:28 ` Maxime Bizon
2013-10-22 18:23 ` [PATCH 2/4 net-next] tools: add Generic Netlink switch configuration tool Florian Fainelli
2013-10-22 18:23 ` [PATCH 3/4 net-next] net: phy: add Broadcom B53 switch driver Florian Fainelli
2013-10-22 18:23 ` [PATCH 4/4 net-next] net: phy: add fake " Florian Fainelli
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=526D4B06.8040505@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=blogic@openwrt$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=gary@mlbassoc$(echo .)com \
--cc=jogo@openwrt$(echo .)org \
--cc=john.r.fastabend@intel$(echo .)com \
--cc=nbd@openwrt$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=nhorman@tuxdriver$(echo .)com \
--cc=s.hauer@pengutronix$(echo .)de \
--cc=stephen@networkplumber$(echo .)org \
--cc=vyasevic@redhat$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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