To implement what you want the underlying nic driver should support polling, which is not available yet.
Currently, the handling of of rx interrupts is usually multiplexed with that of other interrupt events in the interrupt handler under legacy interrupt mode, though the ISR focuses mainly on receiving. Under MSI/MSI-X interrupt modes, there may be dedicated ISR for rx, but you still need interfaces to toggle between interrupt mode and polling mode and to do the polling itself. Thanks, Lucy yi zhang - Sun Microsystems - Beijing China wrote: > Seems we can only poll NIC driver's interrupt ISR to receive ethernet > packet from NIC, > > it seems that mac_rx() is just used to handle interrupted received packet. > > I need to manually write a polling function to replace this call back > function. > > question is: can anyone give me some clue on where to find this ISR > function and call it manually? > > Thanks > > James Carlson wrote: >> Garrett D'Amore writes: >> >>> James Carlson wrote: >>> >>>> If we really want a network dump feature (diskless systems?), I think >>>> we ought to take a page from the embedded system book: write a tiny >>>> TFTP implementation. There's not much to it (you just need UDP and IP >>>> headers) and you can poll the driver in a loop. It's simple and safe. >>>> >>>> >>> Yes, that would work.... *if* you can figure out how to poll the >>> driver. For modern NIC drivers, this may not be terribly obvious. >>> (Ancient GLDv2 drivers register their ISR with the framework. *Some* >>> GLDv3 may register a "poll" routine to allow the framework to poll >>> without waiting for a hardware interrupts. But the vast majority of >>> drivers do neither of these.) >>> >> An explicit poll entry point (as is done with serial drivers for >> exactly the same purpose -- dealing with I/O for kernel debug) is what >> I had in mind here. >> >> The driver support issue is just that; we'd have to add this to the >> list of required features for new drivers, and then go back and update >> the old ones. Just as with Brussels or any other new thing we might >> care to do here. >> >> >>>> For what it's worth, the embedded systems I've worked on in the past >>>> place both initial boot and dump logic into the system ROM, so that >>>> there's no way it can be corrupted, and so that it's guaranteed to be >>>> available -- unlike RAM. If we're talking about this feature in order >>>> to support embedded systems, I'd suggest trying something like that. >>>> >>>> >>> Same experience for boot. I've not run into any systems with dump >>> support in firmware, although most of the embedded systems I've worked >>> with have such tight memory constraints on their ROMs that it would be >>> hard to fit anything else in ROM. (Think Sun Rays, certain tiny WiFi >>> access point hardware, and -surprisingly- the E10K control board.) >>> >> The TI34010 X11 terminal I worked on at DG had 32KB of EPROM, and >> supported boot and dump via TFTP and (oddly enough) anonymous ftp. >> The 80376[1] Annex terminal servers that I worked on at Xylogics had >> TFTP, MOP, BFS, IPX, and some other more obscure load/dump mechanisms, >> and did it comfortably in 64K. The MPC860T embedded systems at >> IronBridge had (if I recall correctly) either 512KB or 1MB (depending >> on configuration), into which was included a complete FreeBSD-based >> stack, network management system, shell, VM-based hardware emulator, >> and other components. >> >> I agree that some folks can't seem to scrape together decent >> networking support even when given "lots" of space by embedded >> standards. That doesn't mean that it's impossible or even very hard >> to do. >> >> 1. Yes; 803*7*6 is accurate. It's an obscure part that was once >> somewhat popular for higher-end embedded systems. >> >> > > _______________________________________________ > networking-discuss mailing list > [email protected] > _______________________________________________ networking-discuss mailing list [email protected]
