Linux kernel-network message sending process

The transmission of the message is initiated by the upper layer of the network protocol stack. The upper layer of the network protocol stack constructs a SKB structure that needs to be sent (the SKB already contains the header of the data Link layer) and calls the Dev_queue_xmit function for sending;
Dev_queue_xmit (SKB);
This function first handles some sort of buffer reorganization, computes the checksum, and then begins processing the message.
There are two strategies for sending a message, either a queue or no queue. This is specified by the network device driver when it defines its corresponding dev structure, and the general device uses the queue.
Dev->qdisc points to an instance of a queue that contains the queue itself and the methods for manipulating the queue (Enqueue, dequeue, Requeue). The collection of these methods consists of a queue rule (SKB will be queued in a certain rule, is not necessarily a simple FIFO), and such rules can be used for flow control.
Network device drivers can choose which queues their devices use, or do not use queues.
For a device with a queue, Dev_queue_xmit calls the Dev->qdisc->enqueue method to join the SKB queue and then calls the Qdisc_run function. Instead, Qdisc_run calls Qdisc_restart to process the queue.
Qdisc_restart (Dev);
The main task of this function is to constantly call the Dev->qdisc->dequeue method to remove the message from the queue and call the Dev->hard_start_xmit method to send it. This method is implemented by the device driver, and it will deal with the network device directly and send the message out. If the Qdisc_restart is sent for a long time (more than 1ms) or if the CPU needs to process other processes, the Netif_schedule function will be called to add Dev to the softdate_net output_ Queue (where the device has messages waiting to be sent and will be processed later). It then triggers a NET_TX_SOFTIRQ soft interrupt.
Qdisc_restart calls the Dev->qdisc->dequeue method to remove the message from the queue, and if the message fails to send, Qdisc_restart calls dev->qdisc-> The Requeue method re-skb the queue back. At the same time, the Netif_schedule function will be called to add Dev to the softdate_net output_queue queue (where the device has messages waiting to be sent and will be processed later). It then triggers a NET_TX_SOFTIRQ soft interrupt (see the Soft interrupt section below). Therefore, the corresponding soft interrupt handler function Net_tx_action will be called when the next interrupt arrives.
Qdisc_restart calls the Dev->qdisc->dequeue method to remove the message to be sent from the queue, if the Dev->hard_start_xmit method sends a message successfully, it means that the message has been sent to the network device send buffer, The device automatically sends the message out. When the message is sent, the device notifies the driver via an interrupt. The corresponding interrupt handler also triggers the NET_TX_SOFTIRQ soft interrupt. In addition, the completed SKB will be added to the softdate_net completion_queue queue, waiting to be released.
The soft interrupt Net_tx_softirq is triggered, which causes the Net_tx_action function to be called. The function mainly does two things:
1. Remove each SKB from the Softdate_net completion_queue queue and release it;
2. For Dev in Softdate_net's output_queue queue, call Qdisc_run continue to attempt to send messages in its QDISC queue;
For a device with a queue, its queue is primarily used for traffic control and buffering when sending fails, and for devices that do not have a queue (such as Lo, loopback device), the Dev_queue_xmit function calls Dev->hard_start_xmit to send directly. If the failed message is discarded.

PS: Soft Interrupt
Softirq_vec data has 32 elements, corresponding to can have 32 software interrupts, but in fact, Linux only uses 6 soft interrupts, each corresponding CPU will have a corresponding 32-bit mask __softirq_pending describes the suspended soft interrupt, Each one corresponds to a software interrupt.
The local_softirq_pending () macro is used to select the __softirq_penging mask that corresponds to the current CPU
The Raise_softirq_irqoff () function must be executed in the case of a forbidden interrupt, which first invokes the __raise_softirq_irqoff () macro to activate the software interrupt, in fact, to set the current CPU corresponding to the __softirq_ The pending corresponds to the bit of the soft interrupt to indicate that the soft interrupt has been activated. If the current is in a break or soft interrupt, then the Raise_softirq_irqoff execution ends, otherwise the call WAKEUP_SOFTIRQD () function activates the ksoftirqd/n kernel thread to handle the soft interrupt.
The WAKEUP_SOFTIRQD () function wakes the kernel thread ksoftirqd.

Static intKSOFTIRQD (void*__bind_cpu) {。。。。。。。。。。。。。。。。。。。。。。  while(Local_softirq_pending ()) {/*Preempt Disable stops CPU going offline. If already offline, we ll be on wrong Cpu:don ' t process*/if(Cpu_is_offline (Long) __bind_cpu))GotoWait_to_die;do_softirq ();p reempt_enable_no_resched (); cond_resched ();p reempt_disable (); Preempt_enable (); set_current_state (task_interruptible);} .............. return 0;}

Reference:

http://blog.csdn.net/shaohaigod1981/article/details/4776314
Http://basiccoder.com/kernel-softirq.html

Linux kernel-network message sending process