From owner-freebsd-net Tue Mar 26 23: 0:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7ACFF37B417 for ; Tue, 26 Mar 2002 23:00:05 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA52058; Tue, 26 Mar 2002 22:46:37 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2R6kFt39325; Tue, 26 Mar 2002 22:46:15 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203270646.g2R6kFt39325@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020326222128.A16450@iguana.icir.org> "from Luigi Rizzo at Mar 26, 2002 10:21:28 pm" To: Luigi Rizzo Date: Tue, 26 Mar 2002 22:46:15 -0800 (PST) Cc: Archie Cobbs , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo writes: > > Along those lines, this might be a handy thing to add... > > > > int if_get_next(struct ifnet *ifp); /* runs at splimp() */ > > > > This function tries to "get" the next packet scheduled to go > > out interface 'ifp' and, if successful, puts it on &ifp->if_snd > > (the interface output queue for 'ifp') and returns 1; otherwise, > > it returns zero. > > how is this different from having a longer device queue ? The idea is that if_get_next() may in turn call some scheduling code that intelligently decides what packet gets to go next. So, when this kind of thing is enabled, the device queue basically always has either zero or one packets on it. In effect, this allows you to move the interface output queue out of the (dumb) device driver upwards in the networking stack, where e.g. a netgraph node can make the scheduling decision. The existing fixed length FIFO queues at each device mean you can't do intelligent scheduling of packets, because you can't manage that queue, because part of "managing" the queue is knowing when it goes empty. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message