Wed, Nov 23, 2016 at 01:24:30AM CET, f.faine...@gmail.com wrote: >On 11/22/2016 02:08 PM, Jiri Pirko wrote: >> Tue, Nov 22, 2016 at 06:48:29PM CET, and...@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
