netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
	Jimmy PERCHET <jimmy.perchet@parrot.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: [PATCH RFC 3/5] net:stmmac: ensure we reclaim all dirty descriptors.
Date: Tue, 22 Oct 2013 15:33:50 +0200	[thread overview]
Message-ID: <52667EBE.8050104@st.com> (raw)
In-Reply-To: <1382381375.3284.79.camel@edumazet-glaptop.roam.corp.google.com>

On 10/21/2013 8:49 PM, Eric Dumazet wrote:
> On Mon, 2013-10-21 at 11:32 -0700, Eric Dumazet wrote:
>> On Mon, 2013-10-21 at 15:10 +0200, Jimmy PERCHET wrote:
>>> Hello Peppe,
>>>
>>
>>> I can reproduce this problem by issuing 9KiB jumbo frames on 10MBit/s link.
>>> If socket's wmemory size is about 500kiB (or less), the transfer stall.
>>> (I guess it is reproducible with 1500o frames by decreasing
>>> socket's wmemory to 90KB)
>>> Re-arming the timer fix this behaviour.
>>>
>>> Here my understanding of this issue :
>>> With 9KiB frames and 500kiB of wmemory, only 60 frames can be
>>> prepared in a row. It is below the tx coalescence threshold,
>>> so there will be no interrupt. When the tx coalescence timer
>>> expires (40ms after), only five descriptors have to be
>>> freed (9000*5 @ 10Mbit/s = 34ms), it is not enough to reach
>>> the socket's wake-up threshold. We get into a deadlock :
>>> *Socket is waiting for free buffers before performing new transfer.
>>> *Driver is waiting for new transfer before performing cleanup.
>>>
>>> Maybe, it is not a real life use-case, and is not worth
>>> a patch. What do you think ?
>>>
>>
>> I think there is probably a bug in the driver, a race of some sort,
>> and it would be better to find it and fix it ;)
>>
>
> coalesce params should not be hardcoded, but depend on link speed and
> mtu.
>
> On 10Mbits, and MTU=9000 there is really no point using coalescing !

so the final patch could be to tune/disable the tx coalesce according
to speed and mtu.

Indeed I had added something that can already  help on that.

We can tune the tx_coal_frames and decide to set the IC bit
(interrupt on completion bit) in the frame to be transmitted.
This can be done via ethtool.

This should reduce the mitigation so, for sure, you can tune all in case
of low speed or jumbo. IIRC, you could decide to disable mitigation
at all. To Jimmy, can you try this? In any case, let me know.

Peppe

  reply	other threads:[~2013-10-22 13:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16 15:24 [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation Jimmy Perchet
2013-10-16 15:24 ` [PATCH RFC 1/5] net:stmmac: set threshold/store and forward mode according to mtu size Jimmy Perchet
2013-10-21  8:47   ` Giuseppe CAVALLARO
2013-10-21  9:58     ` Rayagond K
2013-10-21 13:49       ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 2/5] net:stmmac: fix rx buffer allocation Jimmy Perchet
2013-10-21  8:54   ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 3/5] net:stmmac: ensure we reclaim all dirty descriptors Jimmy Perchet
2013-10-16 17:46   ` Sergei Shtylyov
2013-10-18  8:32     ` Jimmy PERCHET
2013-10-21  9:07   ` Giuseppe CAVALLARO
2013-10-21 13:10     ` Jimmy PERCHET
2013-10-21 18:32       ` Eric Dumazet
2013-10-21 18:49         ` Eric Dumazet
2013-10-22 13:33           ` Giuseppe CAVALLARO [this message]
2013-10-16 15:24 ` [PATCH RFC 4/5] net:stmmac: fix jumbo frame handling Jimmy Perchet
2013-10-21 13:40   ` Giuseppe CAVALLARO
2013-10-21 16:28     ` Jimmy PERCHET
2013-10-22 13:24       ` Giuseppe CAVALLARO
2013-10-16 15:24 ` [PATCH RFC 5/5] net:stmmac: asynchronous tx_clean Jimmy Perchet
2013-10-21 13:52   ` Giuseppe CAVALLARO
2013-10-21 16:30     ` Eric Dumazet
2013-10-21 18:05       ` Jimmy PERCHET
2013-10-21 18:24         ` Eric Dumazet
2013-10-16 20:37 ` [PATCH RFC 0/5] net:stmmac: fix jumbo frames handling and optimisation Giuseppe CAVALLARO
2013-10-18 16:24   ` Jimmy PERCHET

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=52667EBE.8050104@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=eric.dumazet@gmail.com \
    --cc=jimmy.perchet@parrot.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).