First note on the IFB.C file header of the Linux kernel:
The purpose of this driver are to provide a device that allows
For sharing of resources:
1) qdiscs/policies that is per device as opposed to system wide.
IFB allows for a device which can is redirected to thus providing
An impression of sharing.
2) allows for queueing incoming traffic for shaping instead of
Dropping.
The original concept is based on what's 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 was 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, and like Tun, IFB is the place where the packets come from and where they go. For Tun, the packet is sent to the character device in XMit, and the packet written from the character device simulates a RX operation on the Tun Nic, which is similar for IFB.
The IFB drive is so simple that it is so short that it can be made clear, then a panorama, and finally a little bit of how to use it, this article is done.
The IFB driver simulates a virtual NIC, which can be seen as a virtual network card with only the TC filtering function, saying that it is only filtering because it does not change the direction of the packet, that is, after the outgoing packet is redirected to IFB, after the IFB TC is filtered, is still sent through the network card before redirection, for a network card received packets, after being redirected to IFB, after the IFB TC filtered, is still redirected before the network card continues to receive processing, whether it is sent from a network card packets or a network card received packets, redirected to IFB, Will go through a dev_queue_xmit operation via the IFB virtual network card. Having said so much, I can see a picture:
Ingress Queue Linux TC is a controlled uncontrolled frame, but this is for the location of the TC, rather than the limitations of the TC itself, in fact, you can fully implement a queue mechanism on the Ingress point, said TC control is not controlled only because the Linux The current implementation of TC does not implement the ingress queue.
Linux has a lot of hooks on the stack, NetFilter of course is the most obvious, it can not only implement firewalls and NAT, can also be a packet on the prerouting Hook point queue to a line, and then send the packet of this queue to a virtual network card, The XMit callback function of the virtual network card puts the packet back to the point where the packet is netfilter stolen, sends a flow control to the virtual network card to implement the Ingress queue in disguise, this is imq principle, it works well, but need to add fields in SKB, Use up also involved in NetFilter configuration, not so pure, so in this thought based on the realization of the IFB drive, the driver directly hanging in the TC itself Ingress Hook, not with the netfilter relationship, However, because the hook mechanism of the TC does not steal a packet and put back the mechanism, so only after the IFB flow control in the IFB Nic XMit function to recall the actual network card Rx once, this implementation and the implementation of the Linux bridge to complete the local The implementation of deliver is the same.
Qdisc multiple NIC sharing in addition to the ingress queue, sharing a root qdisc between multiple network cards is another purpose of IFB implementation, which can be seen from the comments in the file header. If you have 10 NICs and want to implement the same flow control strategy on these 10 NICs, do you need to configure 10 times? Take the same thing out, implement a IFB virtual network card, and then redirect all of the 10 network card traffic to this IFB virtual network card, at this time only need to configure a QDISC on this virtual network card can be.
Performance issues Maybe you think, redirect the traffic of multiple network card to a piece of IFB network card, this is not to have all of the different network card queue by different CPU processing packets queued to IFB virtual network card of a queue by a CPU processing it? In fact, this worry is superfluous.
Yes, the IFB virtual network card has only one network card receive queue and send queue, but this queue is not processed by a CPU, but is the CPU that originally processed the packet (just as far as possible, but can not guarantee that the original processing the packet of the CPU) continue processing, how to do it? In fact, IFB uses the Tasklet to treat the packet send and receive, after the packet enters the XMit function of the FIB, queues the packet, then on this CPU, notice that this CPU is the CPU that originally processed the packet, scheduling a tasklet on this CPU, When the Tasklet is executed, the packet in the queue is taken out for processing, if the egress is redirected to the IFB, the original network card is called XMit, if the ingress is redirected to IFB, the original network card is called RX. Of course, the Tasklet only takes the first packet out of the queue, which is not necessarily queued on the CPU, which may be a loss of performance gains from a bit of cache's high utilization, but in any case, if it's a multi-CPU system, Then obviously Tasklet is not scheduled to execute on only one CPU. Also, the overhead is a bit of the spin lock overhead when you operate a single queue.
The optimization method is obvious, that is, the implementation of the queue as "per CPU", so that not only to ensure the cache high utilization, but also eliminate the operation of a single queue lock overhead.
IFB principle of Linux TC and ingress flow control
