From: Ben Greear <greearb@candelatech.com>
To: "David S. Miller" <davem@redhat.com>
Cc: alan@lxorguk.ukuu.org.uk, ionut@cs.columbia.edu,
linux-kernel@vger.kernel.org, cfriesen@nortelnetworks.com
Subject: Re: want opinions on possible glitch in 2.4 network error reporting
Date: Wed, 06 Feb 2002 21:56:17 -0700 [thread overview]
Message-ID: <3C6208F1.2090307@candelatech.com> (raw)
In-Reply-To: <E16Ydys-0007D6-00@the-village.bc.nu> <3C6200B5.5060704@candelatech.com> <20020206.203838.107294675.davem@redhat.com>
David S. Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Wed, 06 Feb 2002 21:21:09 -0700
>
> Alan Cox wrote:
>
> > UDP is not flow controlled.
>
> If it makes it through sendto, where can it be dropped before it
> hits the wire?
>
> If the packet ends up being fragmented on the way out and the socket
> cannot take on the allocation against it's buffer space.
In the fragmentation case (at least over 1500 MTU ethernet), the
headers are a relatively small portion of the total PDU, right?
So, if we reserved 10-15% (or whatever it works out to) that should
make it so we never drop the packet due to fragmentation, right? I can't see any reason
not to reserve this space, because sending a little later is definately
better than going through the work to send it sooner but then having to
drop it down in the local kernel. We may only want to reserve the buffers
when they are fairly large (ie not you your very small and slow embedded devices
where memory is very precious).
--
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
next prev parent reply other threads:[~2002-02-07 4:56 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
2002-02-07 4:38 ` David S. Miller
2002-02-07 4:56 ` Ben Greear [this message]
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=3C6208F1.2090307@candelatech.com \
--to=greearb@candelatech.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cfriesen@nortelnetworks.com \
--cc=davem@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox