2010/12/1 Jean-Michel Hautbois <jhautbois@xxxxxxxxx>: > 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 > signiïcant 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 ? > > I will now focus on the dma_map_single() and dma_unmap_single functions... > > Thanks in advance for your help, > Best Regards, > > JM > dma_map_single() and dma_unmap_single() have the same instruction set used inside (sync) because there is a cleaning of cache. eieio instruction doesn't seem to be faster and I think that because cache is not inhibited, this is not a good way to do that. The delay introduced by the use of these instructions can be really big (about 70-90Âs) whereas in most cases it is relatively good (about 10-20Âs). This jitter is a problem in my use case, and I think I am not the only one :). One other thing to say : I am using little packets (about 200 bytes). JM -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
