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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
