Linux Kernel Architecture

Chapter 12: Networks

The steps taken byregister_netdeviceare summarized in the code flow diagram in Figure 12-9.

Initialization function available?

Check name and features

Insert into namespace specific list and hashes

register_netdevice

dev_new_index

netdev_register_kobject

net_device->init

Figure 12-9: Code flow diagram forregister_netdevice.

Should a device-specific initialization function be provided bynet_device->init, the kernel calls it

before proceeding any further. A uniqueinterface indexthat identifies the device unambiguously within its

namespace is generated bydev_new_index.Theindexisstoredinnet_device->ifindex. After ensuring

that the chosen name is not already in use and no device features (seeNETIF_F_*in<netdevice.h>for a

list of supported features) that would contradict themselves have been specified, the new device is added

to the generic kernel object model withnetdev_register_kobject. This also creates the sysfs entries

mentioned above. Finally, the device is integrated into the namespace-specific list and the device name

and interface index hash tables.

12.7.2 Receiving Packets

Packets arrive at the kernel at unpredictable times.All modern device drivers use interrupts (discussed

in Chapter 14) to inform the kernel (or the system) of the arrival of a packet. The network driver installs

a handler routine for the device-specific interrupt so that each time an interrupt is raised — whenever a

packet arrives — the kernel invokes the handler function to transfer the data from the network card into

RAM, or to notify the kernel to do this some time later.

Nearly all cards support DMA mode and are able to transfer data to RAM autonomously. However,

these data still needs to be interpreted and processed, and this is only performed later.

TraditionalMethod

Currently the kernel provides two frameworks for packet reception. One of them has been in the kernel

for a long time, and thus is referred to as thetraditional method. This API suffers from problems with very-

high-speed network adapters, though, and thus a new API (which is commonly referred to as NAPI^11 )

has been devised by the network developers. Let us first start with the traditional methods since they are

easier to understand. Besides, more adapters use the old instead of the new variant. This is fine since their

physical transmission speed is not so high as to require the new methods. NAPI is discussed afterward.

(^11) While the name describes precisely that the API isnewin contrast to the old API, the naming scheme does not really scale well.
Since NNAPI seems rather out of question, it remains interesting to see how the next new revision will be named. However, it might
take a while until this problem becomes pressing since the current state of the art does not expose any severe problems that would
justify the creation of another API.