All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Ion Badulescu <ionut@cs.columbia.edu>,
	linux-kernel@vger.kernel.org,
	Chris Friesen <cfriesen@nortelnetworks.com>
Subject: Re: want opinions on possible glitch in 2.4 network error reporting
Date: Wed, 06 Feb 2002 21:21:09 -0700	[thread overview]
Message-ID: <3C6200B5.5060704@candelatech.com> (raw)
In-Reply-To: <E16Ydys-0007D6-00@the-village.bc.nu>



Alan Cox wrote:

>>>That is correct UDP behaviour
>>>
>>This is totally untrue, unless the socket doing non-blocking I/O -- and
>>even then you get -1 and EAGAIN from sendto.
>>
> 
> Not the case.


Are you claiming that you will never see -1 and EAGAIN on a nonblocking
UDP socket with sendto?  If so, I'll bet you a kernel patch that you are not
correct (I get to write the patch and you include it :) )


> 
> 
>>there is no way to "lose" that data before it hits the wire, unless of
>>course the network driver is broken and doesn't plug the upper layers when
>>its TX queue is full.
>>
> 
> UDP is not flow controlled.


If it makes it through sendto, where can it be dropped before it
hits the wire?  I doubt the socket buffers are anthing other than FIFO,
and the same goes for the ethernet/device queue.  Since we (can) know
at sendto whether or not the PDU was enqueued for transmit, it seems
trivial to notify user space of success/failure of the local network
stack, and I believe this is what is done.

Now granted, it can be dropped anywhere outside of the machine, but
I can see no good reason to drop it inside the machine.

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear



  parent reply	other threads:[~2002-02-07  4:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-06 20:31 want opinions on possible glitch in 2.4 network error reporting Chris Friesen
2002-02-06 20:56 ` Richard B. Johnson
2002-02-06 21:45   ` Ben Greear
2002-02-06 22:23   ` Chris Friesen
2002-02-07 13:44     ` Richard B. Johnson
2002-02-07 16:33       ` Gerold Jury
2002-02-07  0:24   ` Alan Cox
2002-02-07  0:26 ` Alan Cox
2002-02-07  1:51   ` Ion Badulescu
2002-02-07  2:08     ` Alan Cox
2002-02-07  2:09       ` Ion Badulescu
2002-02-07  2:34         ` Alan Cox
2002-02-07  2:54           ` Ion Badulescu
2002-02-07 11:11             ` Alan Cox
2002-02-08 16:11               ` Pavel Machek
2002-02-08 21:39                 ` Ion Badulescu
2002-02-07  4:21       ` Ben Greear [this message]
2002-02-07  4:38         ` David S. Miller
2002-02-07  4:56           ` Ben Greear
2002-02-07  4:23     ` Ben Greear
2002-02-07  4:37       ` Ion Badulescu
2002-02-07  9:22   ` Luis Garces
     [not found] <3C6192A5.911D5B4F@nortelnetworks.com.suse.lists.linux.kernel>
2002-02-07  0:06 ` Andi Kleen
2002-02-07 15:59   ` Chris Friesen
2002-02-07 16:01     ` Andi Kleen
     [not found] <E16Ydys-0007D6-00@the-village.bc.nu.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.44.0202062101390.4832-100000@age.cs.columbia.edu.suse.lists.linux.kernel>
2002-02-07  2:47   ` Andi Kleen
2002-02-07  6:25     ` Chris Friesen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C6200B5.5060704@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cfriesen@nortelnetworks.com \
    --cc=ionut@cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.