Date: Wed, 23 Apr 1997 14:12:55 -0700 From: David Greenman <dg@root.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Sujal Patel <smpatel@prognet.com>, current@freebsd.org Subject: Re: Possible networking bug in 2.2.1-Release Message-ID: <199704232112.OAA06084@root.com> In-Reply-To: Your message of "Wed, 23 Apr 1997 10:16:10 EDT." <199704231416.KAA17910@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
><<On Wed, 23 Apr 1997 00:24:26 -0700 (PDT), Sujal Patel <smpatel@prognet.com> said:
>
>> /*
>> * Verify that we have any chance at all of being able to queue
>> * the packet or packet fragments
>> */
>> if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >=
>> ifp->if_snd.ifq_maxlen) {
>> error = ENOBUFS;
>> goto bad;
>> }
>
>This code is bogus, but it is unlikely to be the problem that you are
>seeing.
>
>There are three things wrong with this code:
>
>1) It has a slow divide.
>2) Fragments are a case to worry about on the slow path.
>3) It knows far too much about the drop-tail queueing strategy.
>
>(3) really bites, and when I implemented RED last year I tossed it
>completely. Unfortunately, my RED work has not made it into the main
>line of FreeBSD yet. I hope it will, some day, but it may take a
>while before I have an environment where I can test it again.
Well, I wrote those lines of code. I'd be happy to see them go as long as
the problem that they address is solved some other way. The problem of course
is that one doesn't want fragments to be transmitted unless all of them can
be sent. Otherwise an aggressive application will send out pieces of packets,
clogging up the network with useless junk and not make any forward progress.
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704232112.OAA06084>