mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2025-01-24 15:49:42 +07:00
989d957a8b
Petr Machata says: ==================== TC: Introduce qevents The Spectrum hardware allows execution of one of several actions as a result of queue management decisions: tail-dropping, early-dropping, marking a packet, or passing a configured latency threshold or buffer size. Such packets can be mirrored, trapped, or sampled. Modeling the action to be taken as simply a TC action is very attractive, but it is not obvious where to put these actions. At least with ECN marking one could imagine a tree of qdiscs and classifiers that effectively accomplishes this task, albeit in an impractically complex manner. But there is just no way to match on dropped-ness of a packet, let alone dropped-ness due to a particular reason. To allow configuring user-defined actions as a result of inner workings of a qdisc, this patch set introduces a concept of qevents. Those are attach points for TC blocks, where filters can be put that are executed as the packet hits well-defined points in the qdisc algorithms. The attached blocks can be shared, in a manner similar to clsact ingress and egress blocks, arbitrary classifiers with arbitrary actions can be put on them, etc. For example: red limit 500K avpkt 1K qevent early_drop block 10 matchall action mirred egress mirror dev eth1 The central patch #2 introduces several helpers to allow easy and uniform addition of qevents to qdiscs: initialization, destruction, qevent block number change validation, and qevent handling, i.e. dispatch of the filters attached to the block bound to a qevent. Patch #1 adds root_lock argument to qdisc enqueue op. The problem this is tackling is that if a qevent filter pushes packets to the same qdisc tree that holds the qevent in the first place, attempt to take qdisc root lock for the second time will lead to a deadlock. To solve the issue, qevent handler needs to unlock and relock the root lock around the filter processing. Passing root_lock around makes it possible to get the lock where it is needed, and visibly so, such that it is obvious the lock will be used when invoking a qevent. The following two patches, #3 and #4, then add two qevents to the RED qdisc: "early_drop" qevent fires when a packet is early-dropped; "mark" qevent, when it is ECN-marked. Patch #5 contains a selftest. I have mentioned this test when pushing the RED ECN nodrop mode and said that "I have no confidence in its portability to [...] different configurations". That still holds. The backlog and packet size are tuned to make the test deterministic. But it is better than nothing, and on the boxes that I ran it on it does work and shows that qevents work the way they are supposed to, and that their addition has not broken the other tested features. This patch set does not deal with offloading. The idea there is that a driver will be able to figure out that a given block is used in qevent context by looking at binder type. A future patch-set will add a qdisc pointer to struct flow_block_offload, which a driver will be able to consult to glean the TC or other relevant attributes. Changes from RFC to v1: - Move a "q = qdisc_priv(sch)" from patch #3 to patch #4 - Fix deadlock caused by mirroring packet back to the same qdisc tree. - Rename "tail" qevent to "tail_drop". - Adapt to the new 100-column standard. - Add a selftest ==================== Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.