Message ID | cover.1593209494.git.petrm@mellanox.com |
---|---|
Headers | show |
Series | TC: Introduce qevents | expand |
On Sat, 27 Jun 2020 01:45:24 +0300 Petr Machata <petrm@mellanox.com> wrote: > 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. Would a BPF based hook be more flexible and reuse more existing infrastructure?
Stephen Hemminger <stephen@networkplumber.org> writes: > On Sat, 27 Jun 2020 01:45:24 +0300 > Petr Machata <petrm@mellanox.com> wrote: > >> 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. > > Would a BPF based hook be more flexible and reuse more existing > infrastructure? This does reuse the existing infrastructure though: filters, actions, shared blocks, qdiscs invoking blocks, none of that is new. And BPF can still be invoked though classifier and / or action bpf. It looks like you get the best of both worlds here: something symbolic for those of us that use the filter infrastructure, and a well-defined hook for those of us who like the BPF approach.
From: Petr Machata <petrm@mellanox.com> Date: Sat, 27 Jun 2020 01:45:24 +0300 > 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. ... Series applied, thank you.