From owner-freebsd-net Tue Mar 26 22:15:40 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 515A837B417 for ; Tue, 26 Mar 2002 22:15:34 -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 WAA51833; Tue, 26 Mar 2002 22:10:27 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g2R6A5x39204; Tue, 26 Mar 2002 22:10:05 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200203270610.g2R6A5x39204@arch20m.dellroad.org> Subject: Re: ip_output and ENOBUFS In-Reply-To: <20020325145447.A2986@iguana.icir.org> "from Luigi Rizzo at Mar 25, 2002 02:54:47 pm" To: Luigi Rizzo Date: Tue, 26 Mar 2002 22:10:05 -0800 (PST) Cc: 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: > > >if you could suggest a few modifications that would be required, i'd like > > >to pursue this further. > > > > Look at tsleep/wakeup on ifnet of if_snd. > > I am under the impression that implementing this mechanism would > not be so trivial. It is not immediate to tell back to the caller > on which interface ip_output() failed. Nor there is a common place > that i know of where you can be notified that a packet was successfully > transmitted -- i suspect you should patch all individual drivers. > Finally, there is the question on whether you do a wakeup as soon > as you get a free slot in the queue (in which case you most likely > end up paying the cost of a tsleep/wakeup pair on each transmission), > or you put some histeresys. 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. Then, each device driver can be modified (over time) to invoke this function when it gets a transmit interrupt and it's output queue is empty. If the function returns 1, grab the new packet off the queue and schedule it for transmission. Once this is done it becomes much easier to hack together ideas for queueing and scheduling e.g., a netgraph node that does packet scheduling. I think ALTQ does something like this. It would be nice if it was generic enough that other mechanisms besides ALTQ (like netgraph) could also use it. I'm not that familiar with how ALTQ is implemented. -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