From: Niklas Cassel <niklas.cassel@axis.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Giuseppe CAVALLARO <peppe.cavallaro@st.com>,
Joao Pinto <Joao.Pinto@synopsys.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
David Miller <davem@davemloft.net>, <larper@axis.com>,
<rabinv@axis.com>, netdev <netdev@vger.kernel.org>,
<CARLOS.PALMINHA@synopsys.com>, <Jie.Deng1@synopsys.com>,
Stephen Warren <swarren@nvidia.com>
Subject: Re: Synopsys Ethernet QoS
Date: Mon, 19 Dec 2016 18:58:05 +0100 [thread overview]
Message-ID: <06d47014-5533-e761-2674-17f5688fb13c@axis.com> (raw)
In-Reply-To: <20161214125735.GA19542@amd>
On 12/14/2016 01:57 PM, Pavel Machek wrote:
> Hi!
>
>> So if there is a long time before handling interrupts,
>> I guess that it makes sense that one stream could
>> get an advantage in the net scheduler.
>>
>> If I find the time, and if no one beats me to it, I will try to replace
>> the normal timers with HR timers + a smaller default timeout.
>>
> Can you try something like this? Highres timers will be needed, too,
> but this fixes the logic problem.
>
> You'll need to apply it twice as code is copy&pasted.
>
> Best regards,
Hello Pavel
If I first apply your other fix "stmmac: fix memory barriers",
then I can apply this fix without getting a netdev watchdog timeout on tx queue0,
and everything appears to work as it should.
Regarding to fairness, I can't really see a difference, with or without your patch.
I've noticed that for TX, the streams actually stabilize after 5 seconds or so,
but with the default test length of 10 seconds, it's easy to get confused
by the test result summary. So I guess from a fairness point of view,
TX is not really a problem.
For RX fairness, it is very much a real issue. The streams never stabilize.
One key difference is that RX coalescing is implemented by using the
RX watchdog.
Here is an iperf3 run that went for 30 seconds:
[ 4] 0.00-30.00 sec 1.54 GBytes 440 Mbits/sec 0 sender
[ 4] 0.00-30.00 sec 1.54 GBytes 440 Mbits/sec receiver
[ 6] 0.00-30.00 sec 600 MBytes 168 Mbits/sec 0 sender
[ 6] 0.00-30.00 sec 599 MBytes 168 Mbits/sec receiver
[ 8] 0.00-30.00 sec 1.17 GBytes 334 Mbits/sec 0 sender
[ 8] 0.00-30.00 sec 1.17 GBytes 334 Mbits/sec receiver
[SUM] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec 0 sender
[SUM] 0.00-30.00 sec 3.29 GBytes 942 Mbits/sec receiver
> Pavel
>
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
> */
> priv->tx_count_frames += nfrags + 1;
> if (likely(priv->tx_coal_frames > priv->tx_count_frames)) {
> - mod_timer(&priv->txtimer,
> - STMMAC_COAL_TIMER(priv->tx_coal_timer));
> + if (priv->tx_count_frames == nfrags + 1)
> + mod_timer(&priv->txtimer,
> + STMMAC_COAL_TIMER(priv->tx_coal_timer));
> } else {
> priv->tx_count_frames = 0;
> priv->hw->desc->set_tx_ic(desc);
>
>
next prev parent reply other threads:[~2016-12-19 17:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-09 11:29 Synopsys Ethernet QoS Joao Pinto
2016-12-09 15:33 ` David Miller
2016-12-09 15:36 ` Joao Pinto
2016-12-09 15:41 ` David Miller
2016-12-09 15:54 ` Joao Pinto
2016-12-09 22:25 ` Andy Shevchenko
2016-12-09 22:52 ` Florian Fainelli
2016-12-10 0:16 ` Andy Shevchenko
2016-12-10 1:44 ` Florian Fainelli
2016-12-12 10:19 ` Joao Pinto
2016-12-12 14:11 ` Giuseppe CAVALLARO
2016-12-12 16:25 ` Niklas Cassel
2016-12-12 16:46 ` Stephen Warren
2016-12-13 7:22 ` Giuseppe CAVALLARO
2016-12-13 9:38 ` Niklas Cassel
2016-12-13 9:51 ` Giuseppe CAVALLARO
2016-12-14 12:57 ` Pavel Machek
2016-12-14 13:14 ` Joao Pinto
2016-12-14 19:01 ` stmmac: lockups (was Re: Synopsys Ethernet QoS) Pavel Machek
2016-12-15 11:09 ` Synopsys Ethernet QoS Pavel Machek
2016-12-17 17:38 ` Pavel Machek
2016-12-19 10:55 ` Joao Pinto
2016-12-19 11:01 ` Joao Pinto
2016-12-15 12:05 ` Niklas Cassel
2016-12-19 17:58 ` Niklas Cassel [this message]
2016-12-13 11:49 ` Joao Pinto
2016-12-13 12:31 ` Niklas Cassel
2016-12-13 12:50 ` Lars Persson
2016-12-13 12:56 ` Joao Pinto
2016-12-19 16:05 ` Niklas Cassel
2016-12-14 11:54 ` Pavel Machek
2016-12-10 2:13 ` Jie Deng
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=06d47014-5533-e761-2674-17f5688fb13c@axis.com \
--to=niklas.cassel@axis.com \
--cc=CARLOS.PALMINHA@synopsys.com \
--cc=Jie.Deng1@synopsys.com \
--cc=Joao.Pinto@synopsys.com \
--cc=andy.shevchenko@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=larper@axis.com \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=peppe.cavallaro@st.com \
--cc=rabinv@axis.com \
--cc=swarren@nvidia.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.