Chapter 11. Frame Transmission

Transmission is the term used for frames that leave the system, either because they were sent by the system or because they are being forwarded. In this chapter, we will cover the main tasks involved during the frame transmission data path:

• Enabling and disabling frame transmission for a device

• Scheduling a device for transmission

• Selecting the next frame to transmit among the ones waiting in the device's egress queue

• The transmission itself (we will examine the main function)

Much about transmission is symmetric to the reception process we discussed in Chapter 10: NET_TX_SOFTIRQ is the transmission counterpart of the NET_RX_SOFTIRQ softirq, net_tx_action is the counterpart of net_rx_action, and so on. Thus, if you have studied the earlier chapter, you should find it easy to follow this one. Figure 11-1 compares the logic behind scheduling a device for reception and scheduling a device for transmission. Here are some more similarities:

• poll_list is the list of devices that are polled because they have a nonempty receive queue. output_queue is the list of devices that have something to transmit. poll_list and output_queue are two fields of the softnet_data structure introduced in Chapter 9.

• Only open devices (ones with the _ _LINK_STATE_START flag set) can be scheduled for reception. Only devices with transmission enabled (ones with the _ _LINK_STATE_XOFF flag cleared) can be scheduled for transmission.

• When a device is scheduled for reception, its _ _LINK_STATE_RX_SCHED flag is set. When a device is scheduled for transmission, its _ _LINK_STATE_SCHED flag is set.

dev_queue_xmit plays the same role for the egress path that netif_rx plays for the ingress path: each transfers one frame between the driver's buffer and the kernel's queue. The net_tx_action function is called both when there are devices waiting to transmit something and to do housekeeping with the buffers that are not needed anymore. Just as there are queues for ingress traffic, there are queues for egress traffic. The egress queues , handled by Traffic Control (the QoS layer), are actually much more complex than the ingress ones: while the latter are just ordinary First In, First Outs (FIFOs), the former can be hierarchical, represented by trees of queues. Even though Traffic Control has support for ingress queueing too, it's used more for policing and management reasons rather than real queuing: Traffic Control does not use real queues for ingress traffic, but only classifies and applies actions.

Figure 11-1. Scheduling a device: (a) for reception (RX); (b) for transmission (TX)