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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ