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

quoted

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

quoted

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