* 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).