Date: Tue, 26 Mar 2002 22:46:15 -0800 (PST) From: Archie Cobbs <archie@dellroad.org> To: Luigi Rizzo <rizzo@icir.org> Cc: Archie Cobbs <archie@dellroad.org>, freebsd-net@FreeBSD.ORG Subject: Re: ip_output and ENOBUFS Message-ID: <200203270646.g2R6kFt39325@arch20m.dellroad.org> In-Reply-To: <20020326222128.A16450@iguana.icir.org> "from Luigi Rizzo at Mar 26, 2002 10:21:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203270646.g2R6kFt39325>