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  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:   Tue, 14 Apr 2020 05:12:00 +0000
From:   Andy Duan <>
To:     Andrew Lunn <>
CC:     David Miller <>,
        netdev <>,
        Chris Healy <>,
        Chris Heally <>
Subject: RE: [EXT] [PATCH] net: ethernet: fec: Replace interrupt driven MDIO
 with polled IO

From: Andrew Lunn <> Sent: Tuesday, April 14, 2020 11:49 AM
> On Tue, Apr 14, 2020 at 03:07:09AM +0000, Andy Duan wrote:
> > From: Andrew Lunn <> Sent: Tuesday, April 14, 2020 8:46
> > AM
> > > Measurements of the MDIO bus have shown that driving the MDIO bus
> > > using interrupts is slow. Back to back MDIO transactions take about
> > > 90uS, with 25uS spent performing the transaction, and the remainder
> > > of the time the bus is idle.
> > >
> > > Replacing the completion interrupt with polled IO results in back to
> > > back transactions of 40uS. The polling loop waiting for the hardware
> > > to complete the transaction takes around 27uS. Which suggests
> > > interrupt handling has an overhead of 50uS, and polled IO nearly
> > > halves this overhead, and doubles the MDIO performance.
> > >
> >
> > Although the mdio performance is better, but polling IO by reading
> > register cause system/bus loading more heavy.
> Hi Andy
> I actually think is reduces the system bus load. With interrupts we have 27uS
> waiting for the interrupt when the bus is idle, followed by 63uS the CPU is
> busy handling the interrupt and setting up the next transfer, which will case
> the bus to be loaded. So the system bus is busy for 63uS per transaction. With
> polled IO, yes the system bus is busy for 27uS polling while the transaction
> happens, and then another 13uS setting up the next transaction. But in total,
> that is only 40uS.
We cannot calculate the bus loading like this number. As you know, interrupt handler
may cost many instructions on cacheable memory accessing, but IO register
accessing is non-cacheable, which bring heavy AIPS bus loading when a flood of
MDIO read/write operations.  But I don't deny your conclusion that system bus
is more busy in interrupt mode than polling mode. 

> So with interrupts we have 63uS of load per transaction, vs 40uS of load per
> transaction for polled IO. Polled IO is better for the bus.
If we switch to polling mode, it is better to add usleep or cpu relax between IO

> I also have follow up patches which allows the bus to be run at higher speeds.
> The Ethernet switch i have on the bus is happy to run a 5MHz rather than the
> default 2.5MHz. 

Please compatible with 2.5Hz for your following patches.


Powered by blists - more mailing lists