netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cong Wang <xiyou.wangcong@gmail.com>
To: Petr Machata <petrm@mellanox.com>
Cc: Linux Kernel Network Developers <netdev@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@mellanox.com>,
	Ido Schimmel <idosch@mellanox.com>
Subject: Re: [RFC PATCH net-next 0/3] TC: Introduce qevents
Date: Mon, 1 Jun 2020 13:01:46 -0700	[thread overview]
Message-ID: <CAM_iQpWE7p6s-SgcG85f1r0jBUGTezZtf68toQivhvBPduC_zQ@mail.gmail.com> (raw)
In-Reply-To: <87o8q5u7hl.fsf@mellanox.com>

On Sat, May 30, 2020 at 1:55 AM Petr Machata <petrm@mellanox.com> wrote:
>
>
> Cong Wang <xiyou.wangcong@gmail.com> writes:
>
> > On Thu, May 28, 2020 at 2:48 AM Petr Machata <petrm@mellanox.com> wrote:
> >> So you propose to have further division within the block? To have sort
> >> of namespaces within blocks or chains, where depending on the context,
> >> only filters in the corresponding namespace are executed?
> >
> > What I suggest is to let filters (or chain or block) decide where
> > they belong to, because I think that fit naturally.
>
> So filters would have this attribute that marks them for execution in
> the qevent context?

If you view it as position rather than qevent, sure, we already need to
specify the "context" for tc filter creations anyway, "dev... parent ..." is
is context to locate the filter placeholders. This is why it makes sense
to add one more piece, say "position", that is "dev... parent... position...".

It is you who calls it qevent which of course looks like only belong to
qdisc's.

>
> Ultimately the qdisc decides what qevents to expose. Qevents are closely
> tied to the inner workings of a qdisc algorithm, they can't be probed as
> modules the way qdiscs, filters and actions can. If a user wishes to
> make use of them, they will have to let qdiscs "dictate" where to put
> the filters one way or another.

For a specific event like early drop, sure. But if we think it generally,
"enqueue" has the same problem, there are a few qdisc's don't even
support filtering (noop). We can just return ENOSUPP anyway.

  reply	other threads:[~2020-06-01 20:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26 17:10 [RFC PATCH net-next 0/3] TC: Introduce qevents Petr Machata
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 [this message]
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=CAM_iQpWE7p6s-SgcG85f1r0jBUGTezZtf68toQivhvBPduC_zQ@mail.gmail.com \
    --to=xiyou.wangcong@gmail.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 \
    --cc=petrm@mellanox.com \
    /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).