Re: Linux UDP Implementation

2006-09-02 Thread Andi Kleen

> It seems that the implementation (at code level) does not match with the 
> actual behaviour. I would like to seek expertise on clarifying my 
> understanding in UDP implementation so that this phenomenon can be 
> explained.

How about you just add some printks or use a tool like systemtap to instrument
the code path?  That should give some insights what is actually going on.

-Andi


-- 
VGER BF report: U 0.473534
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux UDP Implementation

2006-09-01 Thread Gary Chan

Dear Rick,

Thank you for your reply.

I am sorry that I don't quite understand your point. As far as I know, the 
function call udp_flush_pending_frames() in net/ipv4/udp.c is invoked 
regardless of whether the socket is set to either a blocking mode or a 
non-blocking mode. Do you mean that the implementation in the function 
sendto() handles the packet drop at the interface queue by caching data at 
the socket level ? If so, could you please advise me the Linux Kernel source 
file which contains the exact implementation of sendto() API function call 
in Linux ? I tried to locate this souce file using a bottom-up approach 
starting at the function call udp_sendmsg(), -> inet_sendmsg()  in 
net/ipv4/af_inet.c -> sock_sendmsg() in net/socket.c-> sys_sendto() in 
net/socket.c ... but I finally got lost in sys_sendto().


Thank you for your help.

Regards,

Gary

- Original Message - 
From: "Rick Jones" <[EMAIL PROTECTED]>

To: "Gary Chan" <[EMAIL PROTECTED]>
Sent: Friday, September 01, 2006 1:00 AM
Subject: Re: Linux UDP Implementation



Gary Chan wrote:
According to the function call udp_sendmsg() in the source file 
net/ipv4/udp.c (Linux Kernel 2.6.17.11), when an error value is returned 
from the function ip_append_data() due to local device congestion, say 
interface queue overflow,  pending packets in the queue 
sk->sk_write_queue are simply flushed (udp_flush_pending_frames() is 
invoked) without caching for future retransmission.


I called a network API function sendto() to transmit UDP packets in a 
blocking I/O mode at a rate of 100Mbps over the 802.11b wireless ad hoc 
network, the network was overloaded as the maximum transfer rate for 
802.11b was just 11Mbps. Therefore, the outgoing interface queue must be 
full and UDP packets will be dropped eventually. However, I checked that 
there was no packet loss at the receiver side, i.e. the number of packets 
sent from the sender is equal to that received.


It seems that the implementation (at code level) does not match with the 
actual behaviour. I would like to seek expertise on clarifying my 
understanding in UDP implementation so that this phenomenon can be 
explained.


Perhaps you are seeing a difference in the behaviour of blocking vs 
non-blocking sockets?


rick jones 



--
VGER BF report: U 0.5
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html