From: Jakub Kicinski <kuba@kernel.org>
To: Petr Machata <petrm@nvidia.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, <netdev@vger.kernel.org>,
Ido Schimmel <idosch@nvidia.com>,
"David Ahern" <dsahern@kernel.org>,
Donald Sharp <sharpd@nvidia.com>, <mlxsw@nvidia.com>
Subject: Re: [PATCH net-next 1/6] net: nexthop: Add flag to assert that NHGRP reserved fields are zero
Date: Mon, 5 Aug 2024 15:23:44 -0700 [thread overview]
Message-ID: <20240805152344.2aa5f237@kernel.org> (raw)
In-Reply-To: <ba50a38cbf211cc98bdbebfda53226a1785f73e7.1722519021.git.petrm@nvidia.com>
On Thu, 1 Aug 2024 18:23:57 +0200 Petr Machata wrote:
> diff --git a/include/uapi/linux/nexthop.h b/include/uapi/linux/nexthop.h
> index dd8787f9cf39..2ed643207847 100644
> --- a/include/uapi/linux/nexthop.h
> +++ b/include/uapi/linux/nexthop.h
> @@ -33,6 +33,9 @@ enum {
> #define NHA_OP_FLAG_DUMP_STATS BIT(0)
> #define NHA_OP_FLAG_DUMP_HW_STATS BIT(1)
>
> +/* Response OP_FLAGS. */
> +#define NHA_OP_FLAG_RESP_GRP_RESVD_0 BIT(0)
I guess these are op flags, so nobody should have a need to store them,
but having bits mean different things in and out make decoding and
binding generation much harder. Let's not do this unless absolutely
necessary. Perhaps you can start defining response flags from the
"other end", i.e. bit 31? Chances are the two sides will never "meet".
next prev parent reply other threads:[~2024-08-05 22:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 16:23 [PATCH net-next 0/6] net: nexthop: Increase weight to u16 Petr Machata
2024-08-01 16:23 ` [PATCH net-next 1/6] net: nexthop: Add flag to assert that NHGRP reserved fields are zero Petr Machata
2024-08-05 22:23 ` Jakub Kicinski [this message]
2024-08-06 9:48 ` Petr Machata
2024-08-01 16:23 ` [PATCH net-next 2/6] net: nexthop: Increase weight to u16 Petr Machata
2024-08-01 19:39 ` Simon Horman
2024-08-05 12:33 ` Petr Machata
2024-08-06 14:02 ` Przemek Kitszel
2024-08-01 16:23 ` [PATCH net-next 3/6] selftests: router_mpath: Sleep after MZ Petr Machata
2024-08-01 16:24 ` [PATCH net-next 4/6] selftests: router_mpath_nh: Test 16-bit next hop weights Petr Machata
2024-08-01 16:24 ` [PATCH net-next 5/6] selftests: router_mpath_nh_res: " Petr Machata
2024-08-01 16:24 ` [PATCH net-next 6/6] selftests: fib_nexthops: " Petr Machata
2024-08-01 22:52 ` [PATCH net-next 0/6] net: nexthop: Increase weight to u16 Jakub Kicinski
2024-08-05 8:06 ` Petr Machata
2024-08-05 14:31 ` David Ahern
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=20240805152344.2aa5f237@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=sharpd@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).