[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoC8VPOhvPbdbJUrRrAiLaOF2jwsoBkFBEkivPgMzijG5g@mail.gmail.com>
Date: Wed, 17 Apr 2024 17:22:04 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: dsahern@...nel.org, matttbe@...nel.org, martineau@...nel.org,
geliang@...nel.org, kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net,
rostedt@...dmis.org, mhiramat@...nel.org, mathieu.desnoyers@...icios.com,
atenart@...nel.org, mptcp@...ts.linux.dev, netdev@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next v6 1/7] net: introduce rstreason to detect why
the RST is sent
Hello Eric,
On Wed, Apr 17, 2024 at 5:02 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Wed, Apr 17, 2024 at 10:51 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > Add a new standalone file for the easy future extension to support
> > both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
> >
> > This patch only does the preparations for reset reason mechanism,
> > nothing else changes.
> >
> > The reset reasons are divided into three parts:
> > 1) reuse drop reasons for passive reset in TCP
> > 2) reuse MP_TCPRST option for MPTCP
> > 3) our own reasons
> >
> > I will implement the basic codes of active/passive reset reason in
> > those three protocols, which is not complete for this moment. But
> > it provides a new chance to let other people add more reasons into
> > it:)
> >
> > Signed-off-by: Jason Xing <kernelxing@...cent.com>
>
> My original suggestion was to use normal values in 'enum
> skb_drop_reason', even if there was not necessarily a 'drop'
> in the common sense.
>
> https://lore.kernel.org/all/CANn89iJw8x-LqgsWOeJQQvgVg6DnL5aBRLi10QN2WBdr+X4k=w@mail.gmail.com/
>
> This would avoid these ugly casts later, even casting an enum to other
> ones is not very logical.
Thanks for your comment.
It's a little bit tricky. That's the reason I documented and commented
on this in the rstreason.h file. I hope it's not that hard to
understand.
> Going through an u32 pivot is quite a hack.
>
> If you feel the need to put them in a special group, this is fine by me.
Yes, rst reasons only partially rely on the drop reason mechanism to
support passive rst for TCP well, but not supporting other cases. My
final goal is to cover all the cases for the future, so I wish I can
put it into a separate group, then people like me who find it useful
can introduce more reasons into it.
Thanks,
Jason
Powered by blists - more mailing lists