netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux UDP Implementation
@ 2006-08-31  5:56 Gary Chan
       [not found] ` <44F715B5.5070905@hp.com>
  2006-09-02 11:42 ` Andi Kleen
  0 siblings, 2 replies; 3+ messages in thread
From: Gary Chan @ 2006-08-31  5:56 UTC (permalink / raw)
  To: netdev

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.

Thank you. 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linux UDP Implementation
       [not found] ` <44F715B5.5070905@hp.com>
@ 2006-09-02  6:27   ` Gary Chan
  0 siblings, 0 replies; 3+ messages in thread
From: Gary Chan @ 2006-09-02  6:27 UTC (permalink / raw)
  To: Rick Jones, netdev

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" <rick.jones2@hp.com>
To: "Gary Chan" <hpchan5@ie.cuhk.edu.hk>
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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Linux UDP Implementation
  2006-08-31  5:56 Linux UDP Implementation Gary Chan
       [not found] ` <44F715B5.5070905@hp.com>
@ 2006-09-02 11:42 ` Andi Kleen
  1 sibling, 0 replies; 3+ messages in thread
From: Andi Kleen @ 2006-09-02 11:42 UTC (permalink / raw)
  To: Gary Chan; +Cc: netdev


> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-09-02 11:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-31  5:56 Linux UDP Implementation Gary Chan
     [not found] ` <44F715B5.5070905@hp.com>
2006-09-02  6:27   ` Gary Chan
2006-09-02 11:42 ` Andi Kleen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).