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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Nov 2016 09:21:42 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Ido Schimmel <idosch@...sch.org>,
        netdev@...r.kernel.org, davem@...emloft.net,
        bridge@...ts.linux-foundation.org, stephen@...workplumber.org,
        vivien.didelot@...oirfairelinux.com, jiri@...lanox.com,
        idosch@...lanox.com
Subject: Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration

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