Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   tc-bpf    ( 8 )

программируемый классификатор и действия BPF для дисциплин входящей / исходящей очереди (BPF programmable classifier and actions for ingress/egress queueing disciplines)

  Name  |  Synopsis  |  Description  |    Parameters    |  Examples  |  Further reading  |  See also  |

Параметры (Parameters)

object-file
       points to an object file that has an executable and linkable
       format (ELF) and contains eBPF opcodes and eBPF map definitions.
       The LLVM compiler infrastructure with clang(1) as a C language
       front end is one project that supports emitting eBPF object files
       that can be passed to the eBPF classifier (more details in the
       EXAMPLES section). This option is mandatory when an eBPF
       classifier or action is to be loaded.

section is the name of the ELF section from the object file, where the eBPF classifier or action resides. By default the section name for the classifier is called "classifier", and for the action "action". Given that a single object file can contain multiple classifier and actions, the corresponding section name needs to be specified, if it differs from the defaults.

export points to a Unix domain socket file. In case the eBPF object file also contains a section named "maps" with eBPF map specifications, then the map file descriptors can be handed off via the Unix domain socket to an eBPF "agent" herding all descriptors after tc lifetime. This can be some third party application implementing the IPC counterpart for the import, that uses them for calling into bpf(2) system call to read out or update eBPF map data from user space, for example, for monitoring purposes or to push down new policies.

verbose if set, it will dump the eBPF verifier output, even if loading the eBPF program was successful. By default, only on error, the verifier log is being emitted to the user.

direct-action | da instructs eBPF classifier to not invoke external TC actions, instead use the TC actions return codes (TC_ACT_OK, TC_ACT_SHOT etc.) for classifiers.

skip_hw | skip_sw hardware offload control flags. By default TC will try to offload filters to hardware if possible. skip_hw explicitly disables the attempt to offload. skip_sw forces the offload and disables running the eBPF program in the kernel. If hardware offload is not possible and this flag was set kernel will report an error and filter will not be installed at all.

police is an optional parameter for an eBPF/cBPF classifier that specifies a police in tc(1) which is attached to the classifier, for example, on an ingress qdisc.

action is an optional parameter for an eBPF/cBPF classifier that specifies a subsequent action in tc(1) which is attached to a classifier.

classid flowid provides the default traffic control class identifier for this eBPF/cBPF classifier. The default class identifier can also be overwritten by the return code of the eBPF/cBPF program. A default return code of -1 specifies the here provided default class identifier to be used. A return code of the eBPF/cBPF program of 0 implies that no match took place, and a return code other than these two will override the default classid. This allows for efficient, non-linear classification with only a single eBPF/cBPF program as opposed to having multiple individual programs for various class identifiers which would need to reparse packet contents.

bytecode is being used for loading cBPF classifier and actions only. The cBPF bytecode is directly passed as a text string in the form of ´s,c t f k,c t f k,c t f k,...´ , where s denotes the number of subsequent 4-tuples. One such 4-tuple consists of c t f k decimals, where c represents the cBPF opcode, t the jump true offset target, f the jump false offset target and k the immediate constant/literal. There are various tools that generate code in this loadable format, for example, bpf_asm that ships with the Linux kernel source tree under tools/net/ , so it is certainly not expected to hack this by hand. The bytecode or bytecode-file option is mandatory when a cBPF classifier or action is to be loaded.

bytecode-file also being used to load a cBPF classifier or action. It's effectively the same as bytecode only that the cBPF bytecode is not passed directly via command line, but rather resides in a text file.