Date: Sat, 27 Oct 2001 12:37:00 -0700 From: Luigi Rizzo <rizzo@aciri.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Mike Silbersack <silby@silby.com>, Alfred Perlstein <bright@mu.org>, Soren Kristensen <soren@soekris.com>, net@FreeBSD.ORG Subject: Re: NEW CODE: polling support for device drivers. Message-ID: <20011027123700.C80606@iguana.aciri.org> In-Reply-To: <3BDB033C.98ED2BDF@mindspring.com> References: <20011027044854.X88536-100000@achilles.silby.com> <3BDB033C.98ED2BDF@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
And a few more comments on the technical side: On Sat, Oct 27, 2001 at 11:55:56AM -0700, Terry Lambert wrote: ... > PPS: The polling support for device drivers was something I > had discussed with Bill Paul previously. He did not like > the idea of externalizing the entry points for the tx_eof > and rx_eof routines, as it changed the interface, and not > all cards were capable of supporting it, anyway. If you look at the code i posted, what i did to make the architecture sufficiently general was to make polling-aware driver register a single callback, XX_poll(), at the first useful invocation of XX_intr() (this can be made slightly more efficient by using a macro instead of a function for the registering -- but you get the idea). XX_poll() is then invoked with a "count" argument, which is proportional to the amount of resources (typically packet served, or CPU cycles) that the driver is supposed to spend before returning. The beauty of this approach is that the binary interface for the driver does not change, and you can adapt XX_poll() to what the card is actually able to do. It is responsibility of the programmer to code XX_poll() in a sensible way. Typically, the thing you do is to fetch at most "count" packets from the receive ring (because those mean more work for the router), and process most or all pending tx_eof() events and possibly move a larger chunk of packets from ifq_snd to the transmit ring (because this means finalising work already done and freeing resources). The diffs for if_fxp.c and if_dc.c to implement fxp_poll and dc_poll are quite small indeed, and turned out to be rather mechanical. I guess this comes from well designed drivers. > PPPS: A more correct implementation of polling would probably > be implemented using opportunistic timers; due to an office it might be Mohit Aaron's work at RICE ? Anyways, i am not totally sure that opportunistic timers are really necessary, because you probably want some kind of guarantee on your forwarding rate, and this can only be achieved by a fixed timer rate. And it does not make much sense not to poll whenever you have a chance to, because you either have nothing to do (in which case polling costs little more than a function call and a bunch of memory accesses), or you have packets to forward and then you don't want to delay them further. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- 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?20011027123700.C80606>