netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Machata <petrm@mellanox.com>
To: netdev@vger.kernel.org
Cc: Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	jhs@mojatatu.com, jiri@mellanox.com, idosch@mellanox.com,
	Petr Machata <petrm@mellanox.com>
Subject: [RFC PATCH net-next 0/3] TC: Introduce qevents
Date: Tue, 26 May 2020 20:10:04 +0300	[thread overview]
Message-ID: <cover.1590512901.git.petrm@mellanox.com> (raw)

The Spectrum hardware allows execution of one of several actions as a
result of queue management events: 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:

# tc qdisc add dev eth0 root handle 1: \
	red limit 500K avpkt 1K qevent early block 10
# tc filter add block 10 \
	matchall action mirred egress mirror dev eth1

Patch #1 of this set introduces several helpers to allow easy and uniform
addition of qevents to qdiscs. The following two patches, #2 and #3, then
add two qevents to the RED qdisc: "early" qevent fires when a packet is
early-dropped; "mark" qevent, when it is ECN-marked.

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.

Petr Machata (3):
  net: sched: Introduce helpers for qevent blocks
  net: sched: sch_red: Split init and change callbacks
  net: sched: sch_red: Add qevents "early" and "mark"

 include/net/flow_offload.h     |   2 +
 include/net/pkt_cls.h          |  48 +++++++++++++++
 include/uapi/linux/pkt_sched.h |   2 +
 net/sched/cls_api.c            | 107 +++++++++++++++++++++++++++++++++
 net/sched/sch_red.c            | 100 ++++++++++++++++++++++++++----
 5 files changed, 247 insertions(+), 12 deletions(-)

-- 
2.20.1


             reply	other threads:[~2020-05-26 17:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 17:10 Petr Machata [this message]
2020-05-26 17:10 ` [RFC PATCH net-next 1/3] net: sched: Introduce helpers for qevent blocks Petr Machata
2020-05-26 17:10 ` [RFC PATCH net-next 2/3] net: sched: sch_red: Split init and change callbacks Petr Machata
2020-05-26 18:32   ` Jakub Kicinski
2020-05-27 15:23     ` Petr Machata
2020-05-26 17:10 ` [RFC PATCH net-next 3/3] net: sched: sch_red: Add qevents "early" and "mark" Petr Machata
2020-05-26 17:10 ` [RFC PATCH iproute2-next 1/4] uapi: pkt_sched: Add two new RED attributes Petr Machata
2020-05-26 17:10   ` [RFC PATCH iproute2-next 2/4] tc: Add helpers to support qevent parsing Petr Machata
2020-05-26 17:10   ` [RFC PATCH iproute2-next 3/4] man: tc: Describe qevents Petr Machata
2020-05-26 17:10   ` [RFC PATCH iproute2-next 4/4] tc: q_red: Add support for qevents "mark" and "early" Petr Machata
2020-05-27  4:09 ` [RFC PATCH net-next 0/3] TC: Introduce qevents Cong Wang
2020-05-27  9:56   ` Petr Machata
2020-05-28  4:00     ` Cong Wang
2020-05-28  9:48       ` Petr Machata
2020-05-30  4:48         ` Cong Wang
2020-05-30  8:55           ` Petr Machata
2020-06-01 20:01             ` Cong Wang
2020-06-01 13:35         ` Jiri Pirko
2020-06-01 13:40   ` Jiri Pirko
2020-06-01 19:50     ` Cong Wang
2020-06-01 22:37       ` Petr Machata
2020-06-02  6:05       ` Jiri Pirko
2020-06-03  7:05         ` Cong Wang
2020-06-03 10:08           ` Petr Machata
2020-05-27 15:19 ` Vladimir Oltean
2020-05-27 16:25   ` Petr Machata

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1590512901.git.petrm@mellanox.com \
    --to=petrm@mellanox.com \
    --cc=eric.dumazet@gmail.com \
    --cc=idosch@mellanox.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@mellanox.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).