Linux TC ifb principle and ingress flow control, ifbingress
First, paste the annotation of the ifb. c file header of the Linux kernel:
The purpose of this driver is to provide a device that allows
For sharing of resources:
1) qdiscs/policies that are per device as opposed to system wide.
Ifb allows for a device which can be redirected to thus providing
An impression of sharing.
2) Allows for queueing incoming traffic for shaping instead
Dropping.
The original concept is based on what is known as the IMQ
Driver initially written by Martin Devera, later rewritten
By Patrick McHardy and then maintained by Andre Correa.
You need the tc action mirror or redirect to feed this device
Packets.
This program is free software; you can redistribute it and/or
Modify it under the terms of the GNU General Public License
As published by the Free Software Foundation; either version
2 of the License, or (at your option) any later version.
Authors: Jamal Hadi Salim (2005)
Like tun, ifb is also a virtual network card. Like tun, ifb also makes a fuss about where the data packets come from and where they go. For tun, data packets are sent to character devices in xmit, while data packets written from character devices simulate a rx operation on the tun Nic. For ifb, the situation is similar to this.
The ifb driver is so simple that you can clearly describe it if it is so short. Then, let's take a panoramic view and leave some tips on how to use it. This article is complete.
The ifb driver simulates a virtual network card. It can be seen as a virtual network card with only TC filtering. It only supports filtering because it does not change the direction of data packets, that is, after the outbound packet is redirected to the ifb, after the ifb TC filter, the packet is still sent by the NIC before the redirection. For the packets received by a nic, after being redirected to ifb, after being filtered by the TC of ifb, the NIC before the redirection continues to receive data packets, whether from a network card or from a network card, after redirecting to ifb, all requests must go through a dev_queue_xmit operation through the ifb virtual network card. After talking about this, you can see the following figure:
The Linux TC in the ingress queue is a framework of control and distribution control, but this is for the location where TC is placed, rather than the limits of TC itself. In fact, you can implement a queue mechanism on your own on the ingress point, saying that TC control is not controlled only because the current implementation of Linux TC does not implement the ingress queue.
The Linux protocol stack has many hooks. Netfilter is of course the most obvious. It not only implements firewall and NAT, you can also send a data packet to a queue on the PREROUTING hook, and then send the data packet from this queue to a virtual Nic, the xmit callback function of the virtual network card puts the data packets back into the Netfilter node where the data packet STOLEN is taken. When the data packet is sent to the virtual network card, throttling is performed to implement the ingress queue in disguise, this is the principle of IMQ. It works well, but you need to add fields to skb. The configuration of Netfilter should also be involved in use. It is not so pure, therefore, the ifb driver is implemented on the basis of this idea. This driver is directly attached to the ingress hook of TC itself and does not have a relationship with Netfilter, however, because the TC hook mechanism does not steal a data packet and then put it back, therefore, you only need to re-call the rx of the actual Nic In the xmit function of the ifb Nic after the flow control is completed. The implementation of al deliver is exactly the same.
In addition to the ingress queue, multiple NICs of Qdisc share one root Qdisc among multiple NICs. This is another intention of ifb implementation. It can be seen from the annotations of the file header. If you have 10 NICs and want to implement the same traffic control policy on these 10 NICs, do you need to configure 10 times? Extract the same items, implement an ifb virtual network card, and redirect all the traffic of the 10 network cards to the ifb virtual network card, in this case, you only need to configure a Qdisc on the virtual network card.
Performance problems may be caused by redirecting traffic from multiple NICs to one ifb Nic, isn't it necessary to queue all packets processed by different CPUs in different Nic queues to a queue of the ifb virtual Nic for one CPU to process? In fact, this worry is redundant.
Yes, the ifb virtual Nic only has one Nic receiving queue and sending queue, but this queue is not processed by one CPU, but by the CPU that originally processes the packet (just try, but there is no guarantee that it is the CPU that originally processes the data packet.) How can this problem be solved? In fact, ifb uses tasklet to send and receive data packets. After the data packet enters the xmit function of fib, the data packet is discharged into the queue and then on the CPU, note that this CPU is the CPU used to process data packets. A tasklet is scheduled on the current CPU. When the tasklet is executed, the data packets in the queue will be taken out for processing, if the request is redirected to ifb On egress, The xmit of the original Nic is called. If the request is redirected to ifb on ingress, the rx of the original Nic is called. Of course, tasklet only extracts the first data packet in the queue. This data packet is not necessarily discharged into the CPU, which may result in a loss of performance improvement caused by high cache utilization, however, in any case, if it is a multi-CPU system, it is clear that the tasklet will not be scheduled to run on only one CPU. In addition, there is a bit of overhead, that is, the overhead of the spin lock when operating a single queue.
The optimization method is obvious, that is, the queue is implemented into "per CPU", which not only ensures the high utilization of cache, but also avoids the lock overhead of operating a single queue.
How to use linux tc Traffic Control
In linux, the most direct learning method is to look at the official software documentation. Because linux is almost always open-source software, most of the official documents are summary of others' experiences, which is naturally better than the materials we have learned. For some unintelligible terms, you can search for some materials on the Internet, or take a look at other people's blogs and some large forums and other articles. Websites such as linux community and CSDN can be viewed more.
Linux tc command
If you ask for details, you should go directly to the tutorial.
However, it is really a little effort to get started with TC. You should write more and read the scripts written by others to understand what they mean.
Class is the rule branch. If you use TC to limit the speed, you must first write some rules, such as priority and traffic limit.
After the rules are written, filter the data packets to let the system know which packages comply with the rules and let the data packets go through different branches (rules, class) according to your filtering conditions)
The basic steps are as follows. For more information, see the tutorial.
