From: Ido Schimmel <idosch@idosch.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, petrm@nvidia.com,
jiri@nvidia.com, amcohen@nvidia.com, mlxsw@nvidia.com,
Ido Schimmel <idosch@nvidia.com>
Subject: Re: [PATCH net-next 0/5] mlxsw: Add support for RED qevent "mark"
Date: Wed, 20 Jan 2021 11:14:37 +0200 [thread overview]
Message-ID: <20210120091437.GA2591869@shredder.lan> (raw)
In-Reply-To: <20210119142255.1caca7fb@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Jan 19, 2021 at 02:22:55PM -0800, Jakub Kicinski wrote:
> On Sun, 17 Jan 2021 10:02:18 +0200 Ido Schimmel wrote:
> > From: Ido Schimmel <idosch@nvidia.com>
> >
> > The RED qdisc currently supports two qevents: "early_drop" and "mark". The
> > filters added to the block bound to the "early_drop" qevent are executed on
> > packets for which the RED algorithm decides that they should be
> > early-dropped. The "mark" filters are similarly executed on ECT packets
> > that are marked as ECN-CE (Congestion Encountered).
> >
> > A previous patchset has offloaded "early_drop" filters on Spectrum-2 and
> > later, provided that the classifier used is "matchall", that the action
> > used is either "trap" or "mirred", and a handful or further limitations.
>
> For early_drop trap or mirred makes obvious sense, no explanation
> needed.
>
> But for marked as a user I'd like to see a _copy_ of the packet,
> while the original continues on its marry way to the destination.
> I'd venture to say that e.g. for a DCTCP deployment mark+trap is
> unusable, at least for tracing, because it distorts the operation
> by effectively dropping instead of marking.
>
> Am I reading this right?
You get a copy of the packet as otherwise it will create a lot of
problems (like you wrote).
>
> If that is the case and you really want to keep the mark+trap
> functionality - I feel like at least better documentation is needed.
> The current two liner should also be rewritten, quoting from patch 1:
>
> > * - ``ecn_mark``
> > - ``drop``
> > - Traps ECN-capable packets that were marked with CE (Congestion
> > Encountered) code point by RED algorithm instead of being dropped
>
> That needs to say that the trap is for datagrams trapped by a qevent.
> Otherwise "Traps ... instead of being dropped" is too much of a
> thought-shortcut, marked packets are not dropped.
>
> (I'd also think that trap is better documented next to early_drop,
> let's look at it from the reader's perspective)
How about:
"Traps a copy of ECN-capable packets that were marked with CE
(Congestion Encountered) code point by RED algorithm instead of being
dropped. The trap is enabled by attaching a filter with action 'trap' to
the 'mark' qevent of the RED qdisc."
In addition, this output:
$ devlink trap show pci/0000:06:00.0 trap ecn_mark
pci/0000:06:00.0:
name ecn_mark type drop generic true action trap group buffer_drops
Can be converted to:
$ devlink trap show pci/0000:06:00.0 trap ecn_mark
pci/0000:06:00.0:
name ecn_mark type drop generic true action mirror group buffer_drops
"mirror: The packet is forwarded by the underlying device and a copy is sent to
the CPU."
In this case the action is static and you cannot change it.
next prev parent reply other threads:[~2021-01-20 9:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-17 8:02 [PATCH net-next 0/5] mlxsw: Add support for RED qevent "mark" Ido Schimmel
2021-01-17 8:02 ` [PATCH net-next 1/5] devlink: Add ecn_mark trap Ido Schimmel
2021-01-17 8:02 ` [PATCH net-next 2/5] mlxsw: spectrum_trap: " Ido Schimmel
2021-01-17 8:02 ` [PATCH net-next 3/5] mlxsw: spectrum_qdisc: Offload RED qevent mark Ido Schimmel
2021-01-17 8:02 ` [PATCH net-next 4/5] selftests: mlxsw: sch_red_core: Drop two unused variables Ido Schimmel
2021-01-17 8:02 ` [PATCH net-next 5/5] selftests: mlxsw: RED: Add selftests for the mark qevent Ido Schimmel
2021-01-19 22:22 ` [PATCH net-next 0/5] mlxsw: Add support for RED qevent "mark" Jakub Kicinski
2021-01-20 9:14 ` Ido Schimmel [this message]
2021-01-21 0:45 ` Jakub Kicinski
2021-01-21 10:23 ` Ido Schimmel
2021-01-21 17:19 ` Jakub Kicinski
2021-01-23 15:28 ` Ido Schimmel
2021-01-23 19:55 ` Jakub Kicinski
2021-01-24 8:42 ` Ido Schimmel
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=20210120091437.GA2591869@shredder.lan \
--to=idosch@idosch.org \
--cc=amcohen@nvidia.com \
--cc=davem@davemloft.net \
--cc=idosch@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=petrm@nvidia.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).