From: Chris Friesen <cfriesen@nortelnetworks.com>
To: kuznet@ms2.inr.ac.ru
Cc: jamal <hadi@cyberus.CA>, netdev@oss.sgi.com
Subject: Re: PATCH Re: udp weirdness
Date: Tue, 01 Oct 2002 10:26:03 -0400 [thread overview]
Message-ID: <3D99B07B.7050901@nortelnetworks.com> (raw)
In-Reply-To: 200210011353.RAA19504@sex.inr.ac.ru
kuznet@ms2.inr.ac.ru wrote:
> That was tried and failed miserably ages ago. Applications become
> insane when getting this error from logging tons of useless messages
> to abort()ing and cpu hogging. From the other hand silent reaction
> to loss is almost exactly desired behaviour in presence of congestion
> in the most of cases.
>
> I have no idea, why that OSes work. Probably, they are so great that
> never lose packets. We do.
One of the principles of software design that I was taught was the
principle of least surprise.
If I'm looping on a sendto() with a blocking socket, I would expect the
syscall to block until the packet has been handed off to the device
driver. This may mean blocking until local congestion backs off.
If I'm using non-blocking IO and there is local congestion, I would
expect to get ENOBUFS or maybe EAGAIN/EWOULDBLOCK.
The way we do it now means that we can chew up massive amounts of cpu
creating packets in userspace and throwing them away in the kernel, with
no way of knowing from userspace that it is happening. This just
doesn't seem like the right thing to do.
Chris
next prev parent reply other threads:[~2002-10-01 14:26 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-24 6:50 udp weirdness Eric Lemoine
2002-09-27 12:02 ` Eric Lemoine
2002-09-27 14:53 ` jamal
2002-09-27 15:04 ` Matti Aarnio
2002-09-29 14:47 ` jamal
2002-09-30 8:49 ` Eric Lemoine
2002-09-30 11:09 ` jamal
2002-09-30 12:10 ` jamal
2002-09-30 12:23 ` jamal
2002-10-01 0:22 ` PATCH " jamal
2002-10-01 6:35 ` Eric Lemoine
2002-10-01 9:51 ` jamal
2002-10-01 13:53 ` kuznet
2002-10-01 14:14 ` jamal
2002-10-01 14:26 ` Chris Friesen [this message]
2002-10-01 14:40 ` kuznet
2002-10-01 14:52 ` Chris Friesen
2002-10-01 15:31 ` kuznet
2002-10-01 16:16 ` Chris Friesen
2002-10-01 16:41 ` kuznet
2002-10-01 17:17 ` Chris Friesen
2002-10-01 16:42 ` Ben Greear
2002-10-01 16:58 ` Chris Friesen
2002-10-01 17:55 ` jamal
2002-10-01 18:36 ` Chris Friesen
2002-10-01 18:35 ` jamal
2002-10-01 18:54 ` Ben Greear
2002-10-01 19:03 ` Chris Friesen
2002-10-01 18:52 ` Ben Greear
2002-10-02 11:13 ` Eric Lemoine
2002-10-02 14:09 ` Chris Friesen
2002-10-02 15:25 ` Ben Greear
2002-10-03 15:58 ` Eric Lemoine
2002-10-03 16:29 ` kuznet
2002-09-27 15:19 ` Eric Lemoine
2002-09-27 15:57 ` Eric Lemoine
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=3D99B07B.7050901@nortelnetworks.com \
--to=cfriesen@nortelnetworks.com \
--cc=hadi@cyberus.CA \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@oss.sgi.com \
/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 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).