Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration

[Jiri Pirko <jiri@resnulli.us>]

Wed, Nov 23, 2016 at 01:24:30AM CET, f.fainelli@gmail.com wrote:
>On 11/22/2016 02:08 PM, Jiri Pirko wrote:
>> Tue, Nov 22, 2016 at 06:48:29PM CET, andrew@lunn.ch wrote:
>>> Hi Ido
>>>
>>>> First of all, I want to be sure that when we say "CPU port", we're
>>>> talking about the same thing. In mlxsw, the CPU port is a pipe between
>>>> the device and the host, through which all packets trapped to the host
>>>> go through. So, when a packet is trapped, the driver reads its Rx
>>>> descriptor, checks through which port it ingressed, resolves its netdev,
>>>> sets skb->dev accordingly and injects it to the Rx path via
>>>> netif_receive_skb(). The CPU port itself isn't represented using a
>>>> netdev.
>>>
>>> With DSA, we have a real physical ethernet network interface for the
>>> 'cpu' port. It connects to one of the ports of the switch. Frames on
>> 
>> Every port should be visible as a netdevice, including cpu port.
>> Would it make sence to have representors for those?
>
>The CPU port is kind of already visible with DSA since you need the
>switch to be attached to a normal Ethernet MAC driver (later referenced
>as eth0 for simplicity). Since eth0 is going to potentially receive/send
>switch tagged traffic, and the model is to terminate the interfaces at
>the port level, this interface does not really have any meaningful use
>from a data exchange, apart from multiplexing/demultiplexing switch tags
>(when enabled).

But this is not the switch port, but the counterpart on the other end of
MII. There should be 2 netdevices, one for each.


>
>If we did create a "cpu" network device, this interface would not be
>able to send/receive traffic either, because the per-port network
>interfaces are terminated at their level, and the conduit interface is
>just used for transmitting/receiving switch tagged traffic. It does have
>value as a controlling interface only though.

In this case, yes.


>
>As a controlling interface, this can be helpful, but we need to decide
>which side of the switch this CPU interface would represent, is it the
>switch's view of the CPU port, or is the Ethernet MAC view's of the
>switch's CPU port, attached to it (especially true with discrete switch
>chips).
>
>If we did use eth0 as a controlling interface, we need to somehow be
>able to overload (in an objected oriented fashioned) the netdev_ops,
>ethtool_ops and switchdev_ops for that interface so as to make it
>participate in the switch configuration (we actually do this already for
>ethtool statistics, but this is ugly).
>-- 
>Florian