Receiving Packets from the Network Card

This chapter is mostly focused on how the kernel handles the transmission of network packets. We have already glimpsed at many crucial data structures of the networking code, so we will just give a brief description of the other side of the story; namely, how a network packet is received.

The main difference between transmitting and receiving is that the kernel cannot predict when a packet will arrive at a network card device. Therefore, the networking code that takes care of receiving the packets runs in interrupt handlers and deferrable functions.

Let's sketch a typical chain of events occurring when a packet carrying the right hardware address (card identifier) arrives to the network device.

1. The network device saves the packet in a buffer in the device's memory (the card usually keeps several packets at once in a circular buffer).

2. The network device raises an interrupt.

3. The interrupt handler allocates and initializes a new socket buffer for the packet.

4. The interrupt handler copies the packet from the device's memory to the socket buffer.

5. The interrupt handler invokes a function (such as eth_type_trans( ) function for

Ethernet and IEEE 802.3) to determine the protocol of the packet encapsulated in the data link frame.

6. The interrupt handler invokes the netif_rx( ) function to notify the Linux networking code that a new packet is arrived and should be processed.

Of course, the interrupt handler is specific to the network card device. Many device drivers try to be nice to the other devices in the system and move lengthy tasks, such as allocating a socket buffer or copying a packet to deferrable functions.

The netif_rx( ) function is the main entry point of the receiving code of the networking layer (above the network card device driver). The kernel uses a per-CPU queue for the packets that have been received from the network devices and are waiting to be processed by the various protocol stack layers. The function essentially appends the new packet in this queue and invokes cpu_raise_softirq( ) to schedule the activation of the net_rx_softirq softirq. (Remember that the same softirq can be executed concurrently on several CPUs, hence the reason for the per-CPU queue of received packets.)

The net_rx_softirq softirq is implemented by the net_rx_action( ) function, which essentially executes the following operations: [5]

Was this article helpful?

0 0

Post a comment