From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: wenxu@ucloud.cn
Cc: kuba@kernel.org, jhs@mojatatu.com, netdev@vger.kernel.org,
vladbu@nvidia.com, xiyou.wangcong@gmail.com
Subject: Re: [PATCH v4 net-next 3/3] net/sched: sch_frag: add generic packet fragment support.
Date: Wed, 25 Nov 2020 17:04:07 -0300 [thread overview]
Message-ID: <20201125200407.GB449907@localhost.localdomain> (raw)
In-Reply-To: <1606276883-6825-4-git-send-email-wenxu@ucloud.cn>
On Wed, Nov 25, 2020 at 12:01:23PM +0800, wenxu@ucloud.cn wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> Currently kernel tc subsystem can do conntrack in cat_ct. But when several
typo ^^^
> fragment packets go through the act_ct, function tcf_ct_handle_fragments
> will defrag the packets to a big one. But the last action will redirect
> mirred to a device which maybe lead the reassembly big packet over the mtu
> of target device.
>
> This patch add support for a xmit hook to mirred, that gets executed before
> xmiting the packet. Then, when act_ct gets loaded, it configs that hook.
> The frag xmit hook maybe reused by other modules.
(I'm back from PTO)
This paragraph was kept from previous version and now although it can
match the current implementation, it's a somewhat forced
understanding. So what about:
"""
This patch adds support for a xmit hook to mirred, that gets executed
before xmiting the packet. Then, when act_ct gets loaded, it enables
such hook.
The hook may also be enabled by other modules.
"""
Rationale is to not give room for the understanding that the hook is
configurable (i.e., replaceable with something else), to cope with v4
changes.
>
> Signed-off-by: wenxu <wenxu@ucloud.cn>
> ---
> v2: make act_frag just buildin for tc core but not a module
> return an error code from tcf_fragment
> depends on INET for ip_do_fragment
> v3: put the whole sch_frag.c under CONFIG_INET
I was reading on past discussions that led to this and I miss one
point of discussion. Cong had mentioned that as this is a must have
for act_ct, that we should get rid of user visible Kconfigs for it
(which makes sense). v3 then removed the Kconfig entirely.
My question then is: shouldn't it have an *invisible* Kconfig instead?
As is, sch_frag will be always enabled, regardless of having act_ct
enabled or not.
I don't think it's worth tiying this to act_ct itself, as I think
other actions can do defrag later on or so. So I'm thinking act_ct
could select this other Kconfig, that depends on INET, and use it to
enable/disable building this code.
> v4: remove the abstraction for xmit_hook
Other than this, LGTM.
next prev parent reply other threads:[~2020-11-25 20:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 4:01 [PATCH v4 net-next 0/3] net/sched: fix over mtu packet of defrag in wenxu
2020-11-25 4:01 ` [PATCH v4 net-next 1/3] net/sched: fix miss init the mru in qdisc_skb_cb wenxu
2020-11-25 4:01 ` [PATCH v4 net-next 2/3] net/sched: act_mirred: refactor the handle of xmit wenxu
2020-11-25 4:01 ` [PATCH v4 net-next 3/3] net/sched: sch_frag: add generic packet fragment support wenxu
2020-11-25 19:11 ` Jakub Kicinski
2020-11-26 5:03 ` Cong Wang
2020-11-26 13:26 ` Jamal Hadi Salim
2020-11-27 22:37 ` Jakub Kicinski
2020-11-25 20:04 ` Marcelo Ricardo Leitner [this message]
2020-11-26 5:14 ` Cong Wang
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=20201125200407.GB449907@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=jhs@mojatatu.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vladbu@nvidia.com \
--cc=wenxu@ucloud.cn \
--cc=xiyou.wangcong@gmail.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