Florian Fainelli
2016-Nov-23 00:24 UTC
[Bridge] [RFC net-next 0/3] net: bridge: Allow CPU port configuration
On 11/22/2016 02:08 PM, Jiri Pirko wrote:> Tue, Nov 22, 2016 at 06:48:29PM CET, andrew at 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). 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. 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