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: Wed, 23 Oct 2013 10:09:50 -0400 [thread overview]
Message-ID: <5267D8AE.7080009@mojatatu.com> (raw)
In-Reply-To: <5267CFAB.9090100@openwrt.org>
On 10/23/13 09:31, Felix Fietkau wrote:
> On 2013-10-23 2:53 PM, Jamal Hadi Salim wrote:
> So you would like to have 'dummy' netdevs that don't actually work like
> real ones, just to get stats?
Not just stats, but other utilities, example:
*operational status read and admin status control,
*MAC address setting?
*MTU setting
* If something shows up on the cpu port and comes up, we can make it
appear to be from such a netdev (for the case where this applies)
* etc
> Many of these switches are designed to work completely standalone, i.e.
> they receive their configuration once and then do their thing, often
> they don't even have special treatment for the CPU port.
>
So if i understood the worst case scenario:
- no packets will ever come to the CPU
- minimal config only such as configuring ports and what vlans they
accept
- you cant query the device for anything else not even stats
>> Can you at least retrieve the fdb? example how to figure out which
>> port a specific MAC address resides?
> On some of them, but not all.
>
I think this would be a fit for netdev->features to set capabilities at
initialization.
So canSetfdb, canGetfdb, canDelfdb etc
>> can support more than one vlan without having multiple bridges. example:
>> bridgeA: link ports {swp0:vlan1, swp1:vlan2, swp0:vlan4}
>> bridgeB: link ports {swp0:vlan3, swp1:vlan4, swp1:vlan2}
> So even more dummy interfaces that serve no real purpose other than
> configuration?
Yes. It may sound rediculous(trademark for that owned by DaveM), but
given the returns that all other classical linux tools work, I think it
is worth it.
Disclaimer: I still think this part is acrobatic in nature i.e no good
one-to-one mapping
> Correct.
How do you deal with those situations today example when a packet
shows up in the cpu port and they require routing?
Do you have one monolithic switch netdev ?
>I still get the impression that the model you're describing is
> mostly incompatible with what we're trying to do, and comes at the cost
> of quite a bit of extra complexity and bloat, not just on the
> implementation side, but on the configuration side as well.
/Sigh
I understand it is a dilema especially when you have your model proven
already with users.
The danger is one-offs where certain tools only work with certain
instantiations of common features. From a usability perspective,
it would be nice to use iproute2, ifconfig etc on the switch/ports and
not learn another tool (or program the switch to a different API).
> It also seems to make it more difficult to support vendor specific
> features. I strongly doubt that the slight increase in consistency
> between different kinds of switches/bridges is worth all of these extra
> costs.
I am not privy to what specific vendor features exist that are out of
whack. But note:
We have ability to set capabilities (netdev->features is one, but you
can add another netdev->field). Would it not make sense for the driver
to set such capabilities and the generic code to turn on/off certain
things? Example turn on netdev->ops->fdb_add if the switch is capable
etc.
cheers,
jamal
next prev parent reply other threads:[~2013-10-23 14:09 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 [this message]
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
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=5267D8AE.7080009@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