Date: Mon, 26 Nov 2001 13:14:07 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Andrea Campi <andrea@webcom.it> Cc: freebsd-current@FreeBSD.ORG Subject: Re: send_packet: No buffer space available Message-ID: <20011126131407.A7467@technokratis.com> In-Reply-To: <20011126164901.GA554@webcom.it>; from andrea@webcom.it on Mon, Nov 26, 2001 at 05:49:01PM %2B0100 References: <20011121160116.GA6891@webcom.it> <20011121184318.A64569@technokratis.com> <20011126164901.GA554@webcom.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 26, 2001 at 05:49:01PM +0100, Andrea Campi wrote:
> OK, I traced it to sys/netinet/ip_output.c:
>
> /*
> * 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;
> ipstat.ips_odropped++;
> goto bad;
> }
>
> So this means the output queue on my net card is full, right? And I guess
It means that the interface output queue is full, yes.
> there is no easy solution... Oh well, I'll have to cope. But I still wonder,
> shouldn't this show up on netstat -i? netstat -s does show the dropped packets,
> anyway...
I'm not sure about this. In fact, that's a good question. Usually,
if the queue is full, we should increment ifp->if_snd.ifq_drops as well
as ipstat.ips_odropped. Perhaps this test ought to be more like:
[lock ifp->if_snd]
if ((ifp->if_snd.ifq_len + ip->ip_len / ifp->if_mtu + 1) >
ifp->if_snd.ifq_maxlen) {
error = ENOBUFS;
_IFQ_DROP(ifp->if_snd);
ipstat.ips_odropped++;
goto bad;
}
[queue packet...]
[etc...]
[unlock ifp->if_snd]
Note that we presently don't lock anything (this is expected, we
haven't gotten there yet). However, note also that in the new version we
also do an "_IFQ_DROP()" if we have exceeded the ifq_maxlen, and
finally, also note that the new test is ">" and not ">=" - I don't know
why it is ">=" to begin with. One would think that we should be testing
for whether we are going to _exceed_ ifq_maxlen, not if we're going to
reach it (we should be allowed to reach it).
You should take my suggestion here with a grain of salt, and I think
the best person to comment on this is Jonathan Lemon. <summons jlemon>
> So, no solution, right? :(
Well, you're sending out packets faster than your hardware can
transmit them. You can `artificially' define IFQ_MAXLEN to something
greater than 50 but practically, you probably won't get much besides for
consuming more memory for the output queue.
> Bye,
> Andrea
>
> --
> The best things in life are free, but the
> expensive ones are still worth a look.
>
--
Bosko Milekic
bmilekic@technokratis.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011126131407.A7467>