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  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 <>
To:     Florian Fainelli <>
Cc:     Andrew Lunn <>, Ido Schimmel <>,,,,,,,
Subject: Re: [RFC net-next 0/3] net: bridge: Allow CPU port configuration

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

Powered by blists - more mailing lists