OSDev.org

I've been thinking a little about receiving packets. By my understanding, I receive an interrupt whenever a packet is received. On the other hand, the vast numbers of packets received just by browsing the internet would slow down the computer as it processes the interrupts. But this doesn't happen on any recent computers I've heard of. Does an interrupt happen every N packets, or does the chip break the data down into larger segments?

Well, I don't think that's so surprising. Interrupts happen hundreds (or sometimes thousands) of times every second due to just the PIT, and that only uses a small fraction of the processor time. If you receive 512 bytes from a packet at 1 MHz, you would have a 4 Gb/s connection. These interrupts don't have to make context switches, so in total, they probably take less time than the scheduler if written well.

I believe device drivers are able to receive multiple frames each time they service an interrupt. Someone should be able to confirm this.

Basically, I think you would get an interrupt, and try to grab as many frames that are available at that time.

basically, when you receive a Rx interrupt, you need to service all of the packets in the current buffer. The RTL8139 has buffer status bits that you can check to see if there are still packets remaining so that you can handle all of the buffered packets per interrupt. The RTL8169, i8253x, and i8253x chipsets require you to check the next packet descriptor to see if hardware has already returned control to software (meaning it has finished placing a packet into memory and is ready for service) per interrupt.

I find it wise to set a small delay for Rx interrupts to somewhat solve the problem you expressed concern over. This way, say you're getting a full Gbps that needs to generate an interrupt every time you clear an Rx interrupt, if you put a (very) small delay for the Rx, you can process many packets at a time without having to run through your ISR back-end code every time.

[edit]There are also thresholds you can set so that you only get interrupts once a certain amount of data has accumulated (this both applies to the chip->RAM and FIFO->DMA transactions iirc). Even though it's already been said, these ISRs shouldn't be *that* bulky, but then again, it depends on how well your TCP/IP parser is coded and how fast your lower-level memory operations are. [/edit]

And theres also the poll option, that some use including me, menuetOS etc.

I'd go against that, since polling takes a lot (if not all) of the CPU time.

Essentially a modern network interface card (NIC) works as follows:
The driver sets up two rings with descriptors. One for outgoing packets and one for incoming packets. For outgoing packets, each descriptor contains a pointer to the memory location and size of a packet. For incoming packets, each descriptor points to where in in memory to place an incoming packet. Typically, there's a synchronization protocol between the driver and the hardware where a bit in a descriptor indicates whether the descriptor points to a packet or not. The bit is set by the driver for outgoing packets, and set by the network interface card for incoming packets. In the case of incoming packets, most modern NICs can be programmed to trigger an interrupt immediately upon arrival of a packet, or to delay the interrupt issuing for a specific amount of time. When the interrupt is issued, and the driver receives control, the incoming ring is typically traversed until reaching a descriptor that doesn't point to a packet (i.e. the synchronization bit is not set). As such, the cost of interrupt processing is amortized over many incoming packets. This explanation is quite simplified, but captures the big picture.

Occ

I hadn't thought about using buffers - this idea seems to make sense. I'll have to look into the details of the cards quite a bit more to fully understand them, but thank you to everyone for putting me on the right lines