программируемый классификатор и действия BPF для дисциплин входящей / исходящей очереди (BPF programmable classifier and actions for ingress/egress queueing disciplines)
Имя (Name)
BPF - BPF programmable classifier and actions for ingress/egress
queueing disciplines
Синопсис (Synopsis)
eBPF classifier (filter) or action:
tc filter ... bpf [ object-file OBJ_FILE ] [ section CLS_NAME ] [
export UDS_FILE ] [ verbose ] [ direct-action | da ] [ skip_hw |
skip_sw ] [ police POLICE_SPEC ] [ action ACTION_SPEC ] [ classid
CLASSID ]
tc action ... bpf [ object-file OBJ_FILE ] [ section CLS_NAME ] [
export UDS_FILE ] [ verbose ]
cBPF classifier (filter) or action:
tc filter ... bpf [ bytecode-file BPF_FILE | bytecode
BPF_BYTECODE ] [ police POLICE_SPEC ] [ action ACTION_SPEC ] [
classid CLASSID ]
tc action ... bpf [ bytecode-file BPF_FILE | bytecode
BPF_BYTECODE ]
Описание (Description)
Extended Berkeley Packet Filter ( eBPF ) and classic Berkeley
Packet Filter (originally known as BPF, for better distinction
referred to as cBPF here) are both available as a fully
programmable and highly efficient classifier and actions. They
both offer a minimal instruction set for implementing small
programs which can safely be loaded into the kernel and thus
executed in a tiny virtual machine from kernel space. An in-
kernel verifier guarantees that a specified program always
terminates and neither crashes nor leaks data from the kernel.
In Linux, it's generally considered that eBPF is the successor of
cBPF. The kernel internally transforms cBPF expressions into
eBPF expressions and executes the latter. Execution of them can
be performed in an interpreter or at setup time, they can be
just-in-time compiled (JIT'ed) to run as native machine code.
Currently, the eBPF JIT compiler is available for the following
architectures:
* x86_64 (since Linux 3.18)
* arm64 (since Linux 3.18)
* s390 (since Linux 4.1)
* ppc64 (since Linux 4.8)
* sparc64 (since Linux 4.12)
* mips64 (since Linux 4.13)
* arm32 (since Linux 4.14)
* x86_32 (since Linux 4.18)
Whereas the following architectures have cBPF, but did not (yet)
switch to eBPF JIT support:
* ppc32
* sparc32
* mips32
eBPF's instruction set has similar underlying principles as the
cBPF instruction set, it however is modelled closer to the
underlying architecture to better mimic native instruction sets
with the aim to achieve a better run-time performance. It is
designed to be JIT'ed with a one to one mapping, which can also
open up the possibility for compilers to generate optimized eBPF
code through an eBPF backend that performs almost as fast as
natively compiled code. Given that LLVM provides such an eBPF
backend, eBPF programs can therefore easily be programmed in a
subset of the C language. Other than that, eBPF infrastructure
also comes with a construct called "maps". eBPF maps are
key/value stores that are shared between multiple eBPF programs,
but also between eBPF programs and user space applications.
For the traffic control subsystem, classifier and actions that
can be attached to ingress and egress qdiscs can be written in
eBPF or cBPF. The advantage over other classifier and actions is
that eBPF/cBPF provides the generic framework, while users can
implement their highly specialized use cases efficiently. This
means that the classifier or action written that way will not
suffer from feature bloat, and can therefore execute its task
highly efficient. It allows for non-linear classification and
even merging the action part into the classification. Combined
with efficient eBPF map data structures, user space can push new
policies like classids into the kernel without reloading a
classifier, or it can gather statistics that are pushed into one
map and use another one for dynamically load balancing traffic
based on the determined load, just to provide a few examples.
