RE: [microblaze-uclinux] reschedule problem

["Brettschneider Falk" <fbrettschneider@xxxxxxxxxxxxxxx>]

Hi,
FYI: I found a way to improve the IRQ-latency.

After I reduced all socket send-buffer-sizes to the size of just 1 TCP packet (~1600 bytes), the TCP/IP stack cannot schedule more than 1 packet for delayed sending, so to speak this way immediate sending is forced. This reduces the time window when the TCP/IP stack blocks kernel preemption due processing such queue of packets to transmit.
Function setsocketopt(..., SOL_SOCKET, SO_SNDBUF, (char*)bufSize, ...) is your friend. The bigger the send buffer is (and you send a huge data block to remote), the longer kernel preemption will be blocked.

In my opinion it's a bad design to have the whole TCP/IP stack for receiving in softIRQ context, as well as for sending. At least it looks to me it is this way with the linux-2.6.x-petalogix/drivers/net/xilinx_emac sources. It should be moved to a separate kernel thread to prevent that blocking of the kernel preemption.

Cheers, Falk


Brettschneider, Falk wrote:
> 
> Rescheduling of my user app after the execution of the 
> interrupt service routine in my driver fails only sometimes. 
> This is exactly the case when a concurrently working 
> TCP-sending thread temporarily disables kernel preemption. 
> I've seen it happens e.g. with rcu_read_lock_bh() in 
> ./net/core/dev.c:dev_queue_xmit(). Another disabling of 
> preemption happens in ./net/ipv4/tcp.c:tcp_sendmsg() at goto 
> jump label "wait_for_memory:" when the TCP stack starts to 
> wait for the releasing of a socket buffer.

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/