From: Jakub Kicinski <kuba@kernel.org>
To: Gal Pressman <gal@nvidia.com>
Cc: Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
netdev@vger.kernel.org, Simon Horman <horms@kernel.org>,
Andrew Lunn <andrew@lunn.ch>, Tariq Toukan <tariqt@nvidia.com>
Subject: Re: [PATCH net-next] ethtool: Block setting of symmetric RSS when non-symmetric rx-flow-hash is requested
Date: Mon, 24 Mar 2025 07:35:09 -0700 [thread overview]
Message-ID: <20250324073509.6571ade3@kernel.org> (raw)
In-Reply-To: <eb3badef-2603-4bab-8d7a-c3a90c28dc64@nvidia.com>
On Tue, 18 Mar 2025 11:00:10 +0200 Gal Pressman wrote:
> > I guess something alike the following could be quite common or at least
> > possible:
> >
> > #ifdef AH_V4_FLOW
> >
> > // kernel support AH flow, implement user-space side
> >
> > #else
> >
> > // fail on any AH-flow related code path
> >
> > #endif
>
> Right, thanks Paolo!
I don't see a v2, so commenting here.
I believe that we have had this conversation in BPF context in the past.
BPF likes to have things in enums because enums are preserved in debug
info / BTF and defines (obviously) aren't. So we converted a bunch of
things in uAPI to enums in the past for BPF's benefit. While Paolo's
concern is correct (and I believe I voiced similar concerns myself),
in practice we have never encountered any issues.
No strong preference from my side, but FWIW I think there's significant
precedent for such conversions.
One nit if you decide to keep the enum, Gal, please keep the comments
aligned.
next prev parent reply other threads:[~2025-03-24 14:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 7:23 [PATCH net-next] ethtool: Block setting of symmetric RSS when non-symmetric rx-flow-hash is requested Gal Pressman
2025-03-17 15:07 ` Simon Horman
2025-03-18 7:26 ` Gal Pressman
2025-03-17 20:19 ` Paolo Abeni
2025-03-18 7:28 ` Gal Pressman
2025-03-18 7:36 ` Paolo Abeni
2025-03-18 9:00 ` Gal Pressman
2025-03-24 14:35 ` Jakub Kicinski [this message]
2025-03-24 14:56 ` Gal Pressman
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=20250324073509.6571ade3@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=horms@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tariqt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.