RE: [PATCH] r8169: introduce polling method for link change

From: Andrew Lunn

Sent: 07 June 2021 13:50

On Mon, Jun 07, 2021 at 12:32:29PM +0000, David Laight wrote:

quoted

From: Koba Ko

quoted

Sent: 07 June 2021 05:35

...

quoted

After consulting with REALTEK, I can identify RTL8106e by PCI_VENDOR
REALTEK, DEVICE 0x8136, Revision 0x7.
I would like to make PHY_POLL as default for RTL8106E on V2.
because there's no side effects besides the cpu usage rate would be a
little higher,
How do you think?

If reading the PHY registers involves a software bit-bang
of an MII register (rather than, say, a sleep for interrupt
while the MAC unit does the bit-bang) then you can clobber
interrupt latency because of all the time spent spinning.

That is not what PHY IRQ/POLL means in the PHY subsystem.

Many PHYs don't actually have there interrupt output connected to a
GPIO. This is partially because 803.2 C22 and C45 standards don't
define interrupts. Each vendor which supports interrupts uses
proprietary registers. So by default, the PHY subsystem will poll the
status of the PHY once per second to see if the link has changed
state. If the combination of PHY hardware, board hardware and PHY
driver does have interrupts, the PHY subsystem will not poll, but wait
for an interrupt, and then check the status of the link.

I know. I might be 30 years since I wrote anything to read MII
but I don't remember seeing anything that made it less horrid.

One of the MAC units (probably AMD lance based) could be configured
to repeatedly read one PHY register and generate a MAC interrupt
if it changed - but I've not seen that on some later MAC chips.

As for MII bus masters, i only know of one which is interrupt driven,
rather than polled IO, for completion. The hardware is clocking out 64
bits at 2.5MHz. So it is done rather quickly. I profiled that one
using interrupts, and the overhead of dealing with the interrupt is
bigger than polling.

64 bits at 2.5MHz is some 64000 cpu clocks - not inconsiderable.

It has to be said that I don't know how to solve the delays
associated with software bit-bang (apart from persuading the
hardware engineers it isn't a good idea).
With my 'hardware engineer' hat on (I'm currently (ir)responsible
for some FPGA internals as well as the drivers) the logic to
do things like I2C (etc) reads and writes from fpga memory
sits in a tiny corner of a modern device.

One possibility for 'slow polls' is to do them slowly!
One edge per timer tick - although 'tickless' probably
kills that.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)