linux-kernel - Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <3897e83d-83a6-7bb1-311d-ae228390f757@gmail.com>
Date:   Mon, 9 Jan 2017 10:06:39 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...oirfairelinux.com,
        "David S. Miller" <davem@...emloft.net>,
        Andrew Lunn <andrew@...n.ch>,
        Uwe Kleine-König <uwe@...ine-koenig.org>,
        Andrey Smirnov <andrew.smirnov@...il.com>
Subject: Re: [PATCH net-next v2] net: dsa: make "label" property optional for
 dsa2

On 01/09/2017 09:58 AM, Jiri Pirko wrote:
> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@...il.com wrote:
>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@...oirfairelinux.com wrote:
>>>> Hi Jiri,
>>>>
>>>> Jiri Pirko <jiri@...nulli.us> writes:
>>>>
>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>
>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>> from dsa because its use there is incorrect.
>>>>
>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>
>>> Yes, please revert it. It is only in net-next.
>>
>> Maybe the use case can be understood before reverting the change. How do
>> we actually the physical port number of an Ethernet switch per-port
>> network device? The name is not enough, because there are plenty of
>> cases where we need to manipulate a physical port number (be it just for
>> informational purposes).
> 
> Like what?

Specifying the physical port number (and derive a queue number
eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
where there is an action/queue/port destination argument that gets
programmed into the hardware.

You already have the originating port number from the interface you call
the method against, but you also need the destination port number since
that is what the HW understands.

Aside from that, it is useful for allowing interface naming in user
space if you don't want to use labels.

> 
> Why the name is not enough? This is something propagated to userspace
> and never used internally in kernel.

Because the name is not reflective of the port number in some switches.
In my case for instance, we have 5 ports that are named after the
entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
MoCA interface, and the CPU)

0 -> gphy
1 -> rgmii_1
2 -> rgmii_2
7 -> moca
8 -> cpu

> 
> Btw, ndo_get_phys_port_id does not give you number, but arbitrary binary.

It's not entirely arbitrary for DSA switches since the port number is
stored in an u8 whose value is the port number in hexadecimal (as shown
by sysfs at least).
-- 
Florian