Packet reception and interrupts

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
computafreak
Member
Member
Posts: 76
Joined: Sun Dec 14, 2008 1:53 pm

Packet reception and interrupts

Post by computafreak »

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?
User avatar
NickJohnson
Member
Member
Posts: 1249
Joined: Tue Mar 24, 2009 8:11 pm
Location: Sunnyvale, California

Re: Packet reception and interrupts

Post by NickJohnson »

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.
tomos
Posts: 12
Joined: Wed May 13, 2009 4:04 pm

Re: Packet reception and interrupts

Post by tomos »

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.
Developing tomos, Tom's x86 Operating System.
User avatar
01000101
Member
Member
Posts: 1598
Joined: Fri Jun 22, 2007 12:47 pm
Location: New Hampshire, USA
Contact:

Re: Packet reception and interrupts

Post by 01000101 »

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]
User avatar
Dex
Member
Member
Posts: 1444
Joined: Fri Jan 27, 2006 12:00 am
Contact:

Re: Packet reception and interrupts

Post by Dex »

And theres also the poll option, that some use including me, menuetOS etc.
User avatar
Troy Martin
Member
Member
Posts: 1686
Joined: Fri Apr 18, 2008 4:40 pm
Location: Langley, Vancouver, BC, Canada
Contact:

Re: Packet reception and interrupts

Post by Troy Martin »

I'd go against that, since polling takes a lot (if not all) of the CPU time.
Image
Image
Solar wrote:It keeps stunning me how friendly we - as a community - are towards people who start programming "their first OS" who don't even have a solid understanding of pointers, their compiler, or how a OS is structured.
I wish I could add more tex
Occam
Posts: 6
Joined: Fri May 15, 2009 5:26 am

Re: Packet reception and interrupts

Post by Occam »

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
computafreak
Member
Member
Posts: 76
Joined: Sun Dec 14, 2008 1:53 pm

Re: Packet reception and interrupts

Post by computafreak »

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
Post Reply