From: joerg.krause@embedded.rocks (Jörg Krause)
To: linux-arm-kernel@lists.infradead.org
Subject: Low network throughput on i.MX28
Date: Sat, 05 Nov 2016 13:47:35 +0100 [thread overview]
Message-ID: <1478350055.353.4.camel@embedded.rocks> (raw)
In-Reply-To: <1478349578.3405.5.camel@intel.com>
On Sat, 2016-11-05 at 12:39 +0000, Koul, Vinod wrote:
> On Sat, 2016-11-05 at 13:06 +0100, J?rg Krause wrote:
> > @ Vinod
> > In short, I noticed poor performance in the SSP2 (MMC/SD/SDIO)
> > interface on a custom i.MX28 board with a wifi chip attached.
> > Comparing
> > the bandwith with iperf I get >20Mbits/sec on the vendor kernel and
> > <5Mbits/sec on the mainline kernel. I am trying to investigate what
> > the
> > bottleneck is.
>
> is this imx-dma or imx-sdma..
Its' mxs-dma.
>
> >
> > @ Stefan, all
> > My understanding is that the tasklet in this case is responsible
> > for
> > reading the response registers of the DMA controller and return the
> > response to the MMC host driver.
> >
> > The vendor kernel does this in the interrupt routine of mxs-mmc by
> > issueing a complete whereas the mainline kernel does this in the
> > interrupt routine in mxs-dma by scheduling the tasklet.
>
> Is vendor kernel using dmaengine APIs or not?
No. It's using a custom dmaengine.
>
> Okay, if we talk about getting best performance, I always advise
> folks
> to issue next transaction in the interrupt routine and then do
> descriptor management and callback in tasklet.
>
> Some drivers do that correctly but some don't..
Do you have an example for a driver doing it correctly?
> Tasklet can be an issue but only if there is a huge scheduling delay
> for
> the tasklet. You can check using tracing tools and confirm.
Don't think the tasklets is an issue here as I replaced the tasklets in
the dmaengine API by completion (which the vendor kernel uses) and
there are no performance benefits. However, I am not a Linux kernel
developer...
J?rg
next prev parent reply other threads:[~2016-11-05 12:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-12 23:09 Low network throughput on i.MX28 Jörg Krause
2016-10-13 6:48 ` Lothar Waßmann
2016-10-13 19:43 ` Jörg Krause
2016-10-13 20:42 ` Uwe Kleine-König
2016-10-14 6:13 ` Lothar Waßmann
2016-10-15 8:46 ` Jörg Krause
2016-10-15 8:59 ` Stefan Wahren
2016-10-15 9:41 ` Jörg Krause
2016-10-15 16:16 ` Stefan Wahren
2016-10-28 23:07 ` Jörg Krause
2016-10-29 9:08 ` Stefan Wahren
2016-10-29 13:08 ` Jörg Krause
2016-11-02 8:14 ` Jörg Krause
2016-11-02 8:24 ` Stefan Wahren
2016-11-02 8:30 ` Jörg Krause
2016-11-04 18:44 ` Jörg Krause
2016-11-04 19:30 ` Stefan Wahren
2016-11-04 20:56 ` Jörg Krause
2016-11-04 22:42 ` Jörg Krause
2016-11-05 11:33 ` Stefan Wahren
2016-11-05 12:06 ` Jörg Krause
2016-11-05 12:39 ` Koul, Vinod
2016-11-05 12:47 ` Jörg Krause [this message]
2016-11-05 12:48 ` Fabio Estevam
2016-11-05 13:14 ` Jörg Krause
2016-11-05 15:45 ` Koul, Vinod
2016-11-05 22:37 ` Jörg Krause
2016-11-18 23:49 ` Jörg Krause
2016-11-19 11:36 ` Stefan Wahren
2016-11-20 9:14 ` Jörg Krause
2016-10-15 11:18 ` Jörg Krause
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=1478350055.353.4.camel@embedded.rocks \
--to=joerg.krause@embedded.rocks \
--cc=linux-arm-kernel@lists.infradead.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).