netdev - Re: [PATCH net-next 5/7] net: dsa: mv88e6xxx: Add devlink regions

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: <93a2b736-ff45-4529-c63a-b384db12b232@gmail.com>
Date:   Mon, 17 Aug 2020 10:15:07 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>, Chris Healy <cphealy@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>
Subject: Re: [PATCH net-next 5/7] net: dsa: mv88e6xxx: Add devlink regions

On 8/16/20 3:39 PM, Andrew Lunn wrote:
>>> +static const struct devlink_region_ops *mv88e6xxx_region_port_ops[] = {
>>> +	&mv88e6xxx_region_port_0_ops,
>>> +	&mv88e6xxx_region_port_1_ops,
>>> +	&mv88e6xxx_region_port_2_ops,
>>> +	&mv88e6xxx_region_port_3_ops,
>>> +	&mv88e6xxx_region_port_4_ops,
>>> +	&mv88e6xxx_region_port_5_ops,
>>> +	&mv88e6xxx_region_port_6_ops,
>>> +	&mv88e6xxx_region_port_7_ops,
>>> +	&mv88e6xxx_region_port_8_ops,
>>> +	&mv88e6xxx_region_port_9_ops,
>>> +	&mv88e6xxx_region_port_10_ops,
>>> +	&mv88e6xxx_region_port_11_ops,
>>> +};
>>> +
>>
>> Sounds like there should maybe be an abstraction for 'per-port regions' in
>> devlink? I think your approach hardly scales if you start having
>> switches with more than 11 ports.
> 
> mv88e6xxx is unlikely to have more an 11 ports. Marvell had to move
> bits around in registers in non-compatible ways to support the 6390
> family with this number of ports. I doubt we will ever see a 16 port
> mv88e6xxx switch, the registers are just too congested.

Any number greater than 1 could justify finding a solution that scales.

> 
> So this scales as far as it needs to scale.
> 
>>> +/* The ATU entry varies between chipset generations. Define a generic
>>> + * format which covers all the current and hopefully future
>>> + * generations
>>> + */
>>
>> Could you please present this generic format to us? Maybe my interpretation of
>> the word "generic" is incorrect in this context?
> 
> I mean generic across all mv88e6xxx switches. The fid has been slowly
> getting bigger from generation to generation. If i remember correctly,
> it start off as 6 bits. 2 more bits we added, in a different
> register. Then it got moved into a new register and made 14 bits in
> size. There are also some bits in the atu_op register which changed
> meaning over time.
> 
> In order to decode any of this information in the regions, you need to
> known the specific switch the dump came from. But that is the whole
> point of regions.
> 
> https://www.kernel.org/doc/html/latest/networking/devlink/devlink-region.html
> 
>    As regions are likely very device or driver specific, no generic
>    regions are defined. See the driver-specific documentation files
>    for information on the specific regions a driver supports.
> 
> This should also make the context of 'generic' more clear.

Looking at the documentation above (assuming it is up to date), these
are raw hex dumps of the region, which is mildly useful.

If we were to pretty print those regions such that they can fully
replace the infamous debugfs interface patch from Vivien that has been
floated around before, what other information is available (besides the
driver name) for the user-space tools to do that pretty printing?

Right now, as with any single user facility it is a bit difficult to
determine whether a DSA common representation would be warranted.
-- 
Florian