From: Steven Rostedt <rostedt@goodmis.org>
To: Jean-Michel Hautbois <jhautbois@gmail.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
linux-rt-users@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [MPC52xx]Latency issue with DMA on FEC
Date: Wed, 01 Dec 2010 09:52:10 -0500 [thread overview]
Message-ID: <1291215130.4881.55.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <AANLkTi=vAEcPKLqJ_yJt7NLz5JoYvEnt8S8QB99ZBNSX@mail.gmail.com>
On Wed, 2010-12-01 at 09:16 +0100, Jean-Michel Hautbois wrote:
> Hi lists !
>
> I measured the latency and the jitter of the RX and TX ethernet paths
> on my MPC5200 board.
> The RX path is quite good, but the TX path can be slow.
>
> [ 1218.976762] [mpc52xx_fec_start_xmit]Delay >30us for dma_map_single
> => 76364 ns
> [ 1219.188405] [mpc52xx_fec_tx_interrupt]Delay >30us for
> dma_unmap_single => 34515 ns
> [ 1220.628785] [mpc52xx_fec_start_xmit]Delay >30us for
> bcom_submit_next_buffer => 97273 ns
> [ 1225.776784] [mpc52xx_fec_tx_interrupt]Delay >30us for
> dma_unmap_single => 95273 ns
>
> As one can see, this is obviously problematic.
> The first function I analyzed is bcom_submit_next_buffer() => This
> function doesn't do lots of things, except a call to mb().
>
> I have been looking to the "MPC603e RISC Microprocessor User's Manual"
> and especially the chapter named "2.3.4.7 Memory Synchronization
> Instructions—UISA".
>
> Here is a paragraph which explains a lot :
>
> "The functions performed by the sync instruction normally take a
> significant amount of time
> to complete; as a result, frequent use of this instruction may
> adversely affect performance.
> In addition, the number of cycles required to complete a sync
> instruction depends on system
> parameters and on the processor's state when the instruction is issued."
>
> I am using a real time kernel, and this is a problem, as it is not
> deterministic to use this instruction.
> Is there a way to avoid this ?
Don't use that hardware.
When working with drivers there are times you must sync with the device.
And if the device is nondeterministic, then find another set of hardware
to use. Unfortunately, I think you may not find any.
A mb() is usually used if you do a write to device and read from it.
With out it, the CPU could perform the read before the write, which
would give you an incorrect result. There's no other way around that.
-- Steve
>
> I will now focus on the dma_map_single() and dma_unmap_single functions...
>
> Thanks in advance for your help,
> Best Regards,
>
> JM
next prev parent reply other threads:[~2010-12-01 14:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 8:16 [MPC52xx]Latency issue with DMA on FEC Jean-Michel Hautbois
2010-12-01 9:59 ` Jean-Michel Hautbois
2010-12-01 14:52 ` Steven Rostedt [this message]
2010-12-01 15:09 ` David Laight
2010-12-01 15:15 ` Jean-Michel Hautbois
2010-12-01 20:34 ` Micha Nelissen
2010-12-01 21:16 ` Scott Wood
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=1291215130.4881.55.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=eric.dumazet@gmail.com \
--cc=jhautbois@gmail.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.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).