[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [microblaze-uclinux] xenet_FifoSend(struct sk_buff *orig_skb,structnet_device*dev)
Hi again,
I wrote:
> A mysterious time gap of 570us in the logging above is
> between "entered inner while-loop" and "before
> sk_stream_alloc_pskb". It's a bit after
> __tcp_push_pending_frames. I'm not sure but I reckon it's a
> task switch to the receive part of the TCP stack (maybe
> because the TCP-packet with an ACK has been received from my PC).
meanwhile I improved my logging and demystified that time gap. Indead it's a task switch because of the receiving of an incoming TCP packet (likely the ACK). Look here what happens in tcp.c:tcp_sendmsg():
1. entered tcp_sendmsg():
2. entered inner while-loop: 38
3. before skb_add_data(148 bytes): 6
4. after skb_add_data: 36
5. before __tcp_push_pending_frames: 10
6. entered xenet_FifoSend(1514): 287
7. exit xenet_FifoSend: 278
8. after __tcp_push_pending_frames: 59
9. next loop in inner while-loop: 2
10. before sk_stream_alloc_pskb(): 5
11. ---NET-RX-IRQ-(receive ACK)---->
12. entered FifoRecvHandler(64 bytes): 133
13. exit FifoRecvHandler: 148
14. ---soft-IRQ-------------------->
15. entered net_rx_action: 51
16. exit net_rx_action: 248
17. ---back-to-tcp_sendmsg--------->
18. after sk_stream_alloc_pskb: 60
19. before skb_add_data(180 bytes): 20
20. after skb_add_data: 42
21. before tcp_push: 8
22. before TCP_CHECK_TIMER(sk): 41
23. before release_sock(sk): 2
24. entered xenet_FifoSend(234): 525
25. exit xenet_FifoSend: 215
26. after release_sock(sk): 97
27. exit tcp_sendmsg():
a) You see 11., 14. and 17. are context switches between recv and send tasks.
b) 16. shows we have another memcpy() in FifoRecvHandler() because of taking over the bytes given by EMAC and putting them into a TCP packet.
c) 23. till 27. is the sending of the rest of bytes which didn't fit into the TCP packet sent in 6.. It's 328-148==180(+54 header)==234.
d) I wonder why there is that huge waiting in 23. to 24.? Does release_sock(sk) really take so long?
I hope this all helps to understand the time spent for sending in the TCP stack of microblaze-uClinux. Apart from a faster memcpy(), do you see any place where we could improve the speed?
Cheers, Falk
___________________________
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/