netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Chris Healy <cphealy@gmail.com>
Cc: Andy Duan <fugang.duan@nxp.com>,
	David Miller <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [EXT] [PATCH net-next v2 1/3] net: ethernet: fec: Replace interrupt driven MDIO with polled IO
Date: Sun, 19 Apr 2020 22:47:22 +0200	[thread overview]
Message-ID: <20200419204722.GQ836632@lunn.ch> (raw)
In-Reply-To: <CAFXsbZpVSiMYpUaOR=+UEGBgx5kSTzGcftbPe=PPkj_xWhy=bA@mail.gmail.com>

On Sat, Apr 18, 2020 at 03:39:17PM -0700, Chris Healy wrote:
> I did some profiling using an oscilloscope with my NXP Vybrid based
> platform to see what different "sleep_us" values resulted in for start
> of MDIO to start of MDIO transaction times.  Here's what I found:
> 
> 0  - ~38us to ~40us
> 1  - ~48us to ~64us
> 2  - ~48us to ~64us
> 3  - ~48us to ~64us
> 4  - ~48us to ~64us
> 4  - ~48us to ~64us
> 5  - ~48us to ~64us
> 6  - ~48us to ~64us
> 7  - ~48us to ~64us
> 8  - ~48us to ~64us
> 9  - ~56us to ~88us
> 10 - ~56us to ~112us
> 
> Basically, with the "sleep_us" value set to 0, I would get the
> shortest inter transaction times with a very low variance.  Once I
> went to a non-zero value, the inter transaction time went up, as well
> as the variance, which I suppose makes sense....

Hi All

I dug into this, adding some instrumentation. I've been testing on a
Vybrid platform. During boot it does over 6500 transactions in order
to configure 3 switches and one PHY.

With a delay of 0, it polls an average of 62 times, and it needs 29us
to exit the loop. This means one poll takes 0.5uS.

With a delay of 1uS, it polls on average 2 times, and takes on average
45uS to exit the loop. Which suggests the delay takes around 22uS,
despite the request for only 1uS. Looking at the code, it is actually
performing a usleep_range(1, 1). So i'm assuming sleeping is very
expensive, maybe it is using a timer? So we end up with just as much
interrupt work as waiting for the MDIO interrupt?

By swapping to readl_poll_timeout_atomic() i got much better
behaviour. This uses udelay(). Using a delay of 2uS, it loops polling
the completion bit an average of 10 times. It takes 29uS to exist the
loop. This suggests that udelay(2) is pretty accurate.

This seems like a reasonable compromise. The bus load has been reduced
from 62 to 10 poll loops, without increasing the time it takes to exit
the loop by much. And 10 polls allows for significantly faster
completions when using a faster bus clock and preamble suppression.

So i plan to resubmit using readl_poll_timeout_atomic().

   Andrew

  parent reply	other threads:[~2020-04-19 20:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-18  0:03 [PATCH net-next v2 0/3] FEC MDIO speedups Andrew Lunn
2020-04-18  0:03 ` [PATCH net-next v2 1/3] net: ethernet: fec: Replace interrupt driven MDIO with polled IO Andrew Lunn
2020-04-18 13:55   ` [EXT] " Andy Duan
2020-04-18 22:39     ` Chris Healy
2020-04-19  0:35       ` Andrew Lunn
2020-04-19  6:22       ` Andy Duan
2020-04-19 20:47       ` Andrew Lunn [this message]
2020-04-18 16:21   ` Fabio Estevam
2020-04-18 21:06   ` Florian Fainelli
2020-04-18  0:03 ` [PATCH net-next v2 2/3] net: ethernet: fec: Allow configuration of MDIO bus speed Andrew Lunn
2020-04-18  0:34   ` Florian Fainelli
2020-04-18 14:23     ` Andrew Lunn
2020-04-18 16:01       ` Florian Fainelli
2020-04-18 16:49         ` Andrew Lunn
2020-04-18 21:07           ` Florian Fainelli
2020-04-18 21:08   ` Florian Fainelli
2020-04-18  0:03 ` [PATCH net-next v2 3/3] net: ethernet: fec: Allow the MDIO preamble to be disabled Andrew Lunn
2020-04-18  0:39   ` Florian Fainelli
2020-04-18 14:27     ` Andrew Lunn
2020-04-18 16:02       ` Florian Fainelli
2020-04-18 21:09   ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200419204722.GQ836632@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=fugang.duan@nxp.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).