[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoBV77KmL8_d1PTk8muA6Gg3hPYb99BpAXD9W1RcFsg7Bw@mail.gmail.com>
Date: Fri, 19 Apr 2024 07:26:58 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, dsahern@...nel.org, matttbe@...nel.org,
martineau@...nel.org, geliang@...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 0/7] Implement reset reason mechanism to detect
> When I said "If you feel the need to put them in a special group, this
> is fine by me.",
> this was really about partitioning the existing enum into groups, if
> you prefer having a group of 'RES reasons'
Are you suggesting copying what we need from enum skb_drop_reason{} to
enum sk_rst_reason{}? Why not reusing them directly. I have no idea
what the side effect of cast conversion itself is?
If __not__ doing so (copying reasons one by one), for passive rests,
we can totally rely on the drop reason, which means if we implement
more reasons for skb drop happening in reset cases, we don't need to
handle reset cases over and over again (like adding rst reasons just
after newly added drop reasons if without cast conversions). It's
easier to maintain the reset reason part if we can apply the current
patch series.
Thank you.
Powered by blists - more mailing lists