netdev - Re: [RFC net-next PATCH 0/3] net: dsa: mv88e6xxx: Add RMU support

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]

Message-ID: <b388479b-9aff-be1c-c9b3-20d5169c925f@gmail.com>
Date:   Fri, 19 Aug 2022 07:14:25 +0200
From:   Mattias Forsblad <mattias.forsblad@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [RFC net-next PATCH 0/3] net: dsa: mv88e6xxx: Add RMU support

On 2022-08-18 14:31, Andrew Lunn wrote:
> On Thu, Aug 18, 2022 at 12:29:21PM +0200, Mattias Forsblad wrote:
>> The Marvell SOHO switches have the ability to receive and transmit                                                                                                    
>> Remote Management Frames (Frame2Reg) to the CPU through the                                                                                                           
>> switch attached network interface.                                                                                                                                    
>> These frames is handled by the Remote Management Unit (RMU) in                                                                                                        
>> the switch.
> 
> Please try to avoid all the additional whitespace your editor/mailer
> has added.
> 
>> Next step could be to implement single read and writes but we've
>> found that the gain to transfer this to RMU is neglible.
> 
> I agree that RMON is a good first step. Dumping the ATU and VTU would
> also make a lot of sense.
> 
> For general register access, did you try combining multiple writes and
> one read into an RMU packet? At least during initial setup, i suspect
> there are some code flows which follow that pattern with lots of
> writes. And a collection of read/modify/write might benefit.
> 
>     Andrew

In another stack I've used aggregated writes with great improvements so
it that is something that could be investigated. One large oversight when
implementing RMU in HW there is no operation for masked writes which makes
it a bit trickier. It would be great if there was a transaction-based
API which would easier map for aggregated accesses.
Oltean mentioned something about qck8k that I'll have a look into.