[MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Jean-Michel Hautbois
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

Re: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Jean-Michel Hautbois
2010/12/1 Jean-Michel Hautbois : > 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.1

Re: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Steven Rostedt
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

RE: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread David Laight
> 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. Possibly the synchronisation functions are doing significantly more work than is re

Re: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Jean-Michel Hautbois
2010/12/1 David Laight : > >> 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. > > Possibly the synchronisation functions are doing sig

Re: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Micha Nelissen
David Laight wrote: The in_le32() not only contains the unwanted 'sync', but also a 'twi' (trap immediate - NFI exactly what this does) and 'isync'. The 'isync' is particularly horrid and unnecessary (aborts the instruction queue and refeches the opcode bytes). I've also wondered why some time

Re: [MPC52xx]Latency issue with DMA on FEC

2010-12-01 Thread Scott Wood
On Wed, 1 Dec 2010 15:09:54 + David Laight wrote: > The in_le32() not only contains the unwanted 'sync', but also > a 'twi' (trap immediate - NFI exactly what this does) and 'isync'. It turns a data dependency into a flow dependency. It's basically equivalent to: lwz rX, ... cmpwr