From: Petr Machata <petrm@mellanox•com>
To: Stephen Hemminger <stephen@networkplumber•org>
Cc: netdev@vger•kernel.org, David Miller <davem@davemloft•net>,
"Jakub Kicinski" <kuba@kernel•org>,
Cong Wang <xiyou.wangcong@gmail•com>,
"Eric Dumazet" <eric.dumazet@gmail•com>,
jiri@mellanox•com, idosch@mellanox•com
Subject: Re: [PATCH net-next v1 0/5] TC: Introduce qevents
Date: Mon, 29 Jun 2020 15:21:04 +0200 [thread overview]
Message-ID: <87imfaj9dr.fsf@mellanox.com> (raw)
In-Reply-To: <20200626155617.7f6a4c4c@hermes.lan>
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.
next prev parent reply other threads:[~2020-06-29 19:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-26 22:45 [PATCH net-next v1 0/5] TC: Introduce qevents Petr Machata
2020-06-26 22:45 ` [PATCH net-next v1 1/5] net: sched: Pass root lock to Qdisc_ops.enqueue Petr Machata
2020-07-06 19:21 ` Cong Wang
2020-07-07 15:25 ` Petr Machata
2020-07-07 19:41 ` Cong Wang
2020-06-26 22:45 ` [PATCH net-next v1 2/5] net: sched: Introduce helpers for qevent blocks Petr Machata
2020-07-06 19:48 ` Cong Wang
2020-07-07 15:22 ` Petr Machata
2020-07-07 19:13 ` Cong Wang
2020-07-08 12:35 ` Petr Machata
2020-07-08 16:21 ` Petr Machata
2020-07-08 19:09 ` Cong Wang
2020-07-08 19:04 ` Cong Wang
2020-07-08 21:04 ` Petr Machata
2020-07-09 0:13 ` Petr Machata
2020-07-09 19:37 ` Cong Wang
2020-07-10 14:40 ` Petr Machata
2020-07-14 2:51 ` Cong Wang
2020-07-14 9:12 ` Petr Machata
2020-07-07 19:48 ` Cong Wang
2020-07-08 9:19 ` Petr Machata
2020-06-26 22:45 ` [PATCH net-next v1 3/5] net: sched: sch_red: Split init and change callbacks Petr Machata
2020-06-26 22:45 ` [PATCH net-next v1 4/5] net: sched: sch_red: Add qevents "early_drop" and "mark" Petr Machata
2020-06-26 22:45 ` [PATCH net-next v1 5/5] selftests: forwarding: Add a RED test for SW datapath Petr Machata
2020-06-26 22:45 ` [PATCH iproute2-next v1 1/4] uapi: pkt_sched: Add two new RED attributes Petr Machata
2020-06-26 22:45 ` [PATCH iproute2-next v1 2/4] tc: Add helpers to support qevent handling Petr Machata
2020-06-26 22:45 ` [PATCH iproute2-next v1 3/4] man: tc: Describe qevents Petr Machata
2020-06-26 22:45 ` [PATCH iproute2-next v1 4/4] tc: q_red: Add support for qevents "mark" and "early_drop" Petr Machata
2020-06-26 22:56 ` [PATCH net-next v1 0/5] TC: Introduce qevents Stephen Hemminger
2020-06-29 13:21 ` Petr Machata [this message]
2020-06-30 0:15 ` David Miller
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=87imfaj9dr.fsf@mellanox.com \
--to=petrm@mellanox$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=idosch@mellanox$(echo .)com \
--cc=jiri@mellanox$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=stephen@networkplumber$(echo .)org \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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