From owner-freebsd-current Mon Nov 26 10: 7:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from technokratis.com (modemcable099.144-201-24.mtl.mc.videotron.ca [24.201.144.99]) by hub.freebsd.org (Postfix) with ESMTP id 6D65937B419 for ; Mon, 26 Nov 2001 10:07:03 -0800 (PST) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id fAQIE7d07651; Mon, 26 Nov 2001 13:14:07 -0500 (EST) (envelope-from bmilekic) Date: Mon, 26 Nov 2001 13:14:07 -0500 From: Bosko Milekic To: Andrea Campi Cc: freebsd-current@FreeBSD.ORG Subject: Re: send_packet: No buffer space available Message-ID: <20011126131407.A7467@technokratis.com> References: <20011121160116.GA6891@webcom.it> <20011121184318.A64569@technokratis.com> <20011126164901.GA554@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011126164901.GA554@webcom.it>; from andrea@webcom.it on Mon, Nov 26, 2001 at 05:49:01PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. > 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