netdev - Re: dsa: using multi-gbps speeds on CPU port

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]

Date:   Wed, 15 May 2019 09:09:26 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Vivien Didelot <vivien.didelot@...il.com>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: dsa: using multi-gbps speeds on CPU port

On 5/15/19 7:02 AM, Maxime Chevallier wrote:
> Hi Andrew,
> 
> On Wed, 15 May 2019 15:27:01 +0200
> Andrew Lunn <andrew@...n.ch> wrote:
> 
>> I think you are getting your terminology wrong. 'master' is eth0 in
>> the example you gave above. CPU and DSA ports don't have netdev
>> structures, and so any PHY used with them is not corrected to a
>> netdev.
> 
> Ah yes sorry, I'm still in the process of getting familiar with the
> internals of DSA :/
> 
>>> I'll be happy to help on that, but before prototyping anything, I wanted
>>> to have your thougts on this, and see if you had any plans.  
>>
>> There are two different issues here.
>>
>> 1) Is using a fixed-link on a CPU or DSA port the right way to do this?
>> 2) Making fixed-link support > 1G.
>>
>> The reason i decided to use fixed-link on CPU and DSA ports is that we
>> already have all the code needed to configure a port, and an API to do
>> it, the adjust_link() callback. Things have moved on since then, and
>> we now have an additional API, .phylink_mac_config(). It might be
>> better to directly use that. If there is a max-speed property, create
>> a phylink_link_state structure, which has no reference to a netdev,
>> and pass it to .phylink_mac_config().
>>
>> It is just an idea, but maybe you could investigate if that would
>> work.
> 
> Ok I see what you mean, this would allow us to get rid of the phydev
> built from the fixed-link, and the .adjust_link call. I'll prototype
> that, thanks for the hint.

Vladimir mentioned a few weeks ago that he is considering adding support
for PHYLIB and PHYLINK to run without a net_device instance, you two
should probably coordinate with each other and make sure both of your
requirements (which are likely the same) get addressed.
-- 
Florian