Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

[Jamal Hadi Salim <jhs@mojatatu.com>]

I should probably be reading emails backward to catchup, but this
one caught my eye.

On 03/27/14 12:41, Florian Fainelli wrote:

> It duplicates the information when things just work fine, consider an
> external switch connected via RGMII to a CPU Ethernet MAC, you might
> want to get statistics from both sides (the switch CPU port and the
> CPU Ethernet MAC) to diagnose why things are not working as expected,
> which unfortunately happens once in a while with RGMII.
>
> If we expose both net_device, we will be able to retrieve statistics
> about from both sides, without resorting to ad-hoc debugging tools,
> but maybe this is not worth the effort.
>

This is probably the most convincing rationale i have seen
for this netdev. I think the abstraction is what was bothering me
earlier from Jiri's patch. It is not a "master" netdev of the switch
(since a switch port can only be attached to one master),
it is closer to a "conduit" netdev Roopa was alluding to. From
abstraction you dont attach ports to it, it comes with ports - but it is
merely the control for those ports. Would refereing to this port as
"control" be a good way to go forward?
So if i wanted to retrieve hardware stats for sw1p0 i look up its
"control"->dev->somendo and pass it enough information to give me
the hardware stats for sw1p0.
I can see the rate control Sergey is refering to as merely a tc
ingress policer attached on it (which may translate to some hardware
register setting).
Likewise this is probably where my query to "tell me how many
fdb entries you can support" ends up.

>> So there are no reasons
>> to force user to configure this port manually, and automatic
>> configuration of CPU switch port without exporting them as netdev
>> seems as good approach.
>
> Well, maybe that's the answer, since we know that e.g: sw1p3 is always
> connected to e.g: eth0, we could create an automatic bridge between
> those two, this would keep the netdev exposure to user-space, but an
> user would not have to know about that specific detail to get things
> to work.
>

Could ifconfig down of this port have some semantic that nothing comes
to the cpu?

cheers,
jamal