netdev - Re: FEC unbind/bind feature

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: <YF3jZNRvqXm2aLVX@lunn.ch>
Date:   Fri, 26 Mar 2021 14:36:36 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Joakim Zhang <qiangqing.zhang@....com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: FEC unbind/bind feature

On Fri, Mar 26, 2021 at 01:18:52PM +0000, Joakim Zhang wrote:
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: 2021年3月26日 20:34
> > To: Joakim Zhang <qiangqing.zhang@....com>
> > Cc: Florian Fainelli <f.fainelli@...il.com>; hkallweit1@...il.com;
> > netdev@...r.kernel.org
> > Subject: Re: FEC unbind/bind feature
> > 
> > > One more add, yes, I am looking the drivers/net/mdio, it is better to
> > implement standalone MDIO driver when writing the MAC driver at the
> > beginning.
> > > Now if I abstract MDIO driver from FEC driver, dt bindings would change, it
> > will break all existing implementations in the kernel based on FEC driver, let
> > them can't work.
> > > How to compatible the legacy dt bindings? I have no idea now. At the same
> > time, I also feel that it seems not necessary to rewrite it.
> > 
> > I have a reasonable understanding of the FEC MDIO driver. I have broken it a
> > few times :-)
> > 
> > It is going to be hard to make it an independent driver, because it needs access
> > to the interrupt flags and the clocks for power saving. From a hardware
> > perspective, it is not an independent hardware block, it is integrated into the
> > MAC.
> > 
> > XDP probably is your easier path.
> 
> Thanks Andrew for your share, you mean use XDP instead DPDK, right?

Yes. We have much more control over XDP since it is in kernel, and
uses kernel drivers. No need to unbind the FEC, since the FEC is the
driver used by XDP. The down side is, the FEC has not been optimised
for XDP, so you will be using the generic support. Its performance
won't be optimal. To get that, you need to add native XDP support to
the FEC driver.

    Andrew