[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZibrBFnV2kba2UUi@calendula>
Date: Tue, 23 Apr 2024 00:56:04 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Donald Hunter <donald.hunter@...il.com>, netdev@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Jiri Pirko <jiri@...nulli.us>,
Jacob Keller <jacob.e.keller@...el.com>,
Jozsef Kadlecsik <kadlec@...filter.org>,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
donald.hunter@...hat.com
Subject: Re: [PATCH net-next v4 4/4] netfilter: nfnetlink: Handle ACK flags
for batch messages
On Mon, Apr 22, 2024 at 01:33:28PM -0700, Jakub Kicinski wrote:
> On Thu, 18 Apr 2024 09:51:53 -0700 Jakub Kicinski wrote:
> > On Thu, 18 Apr 2024 18:30:55 +0200 Pablo Neira Ayuso wrote:
> > > Out of curiosity: Why does the tool need an explicit ack for each
> > > command? As mentioned above, this consumes a lot netlink bandwidth.
> >
> > I think that the tool is sort of besides the point, it's just a PoC.
> > The point is that we're trying to describe netlink protocols in machine
> > readable fashion. Which in turn makes it possible to write netlink
> > binding generators in any language, like modern RPC frameworks.
> > For that to work we need protocol basics to be followed.
> >
> > That's not to say that we're going to force all netlink families to
> > change to follow extra new rules. Just those that want to be accessed
> > via the bindings.
>
> Pablo, any thoughts? Convinced? Given this touches YNL in significant
> ways I'd prefer to merge it to net-next.
No objections, thanks for asking.
Powered by blists - more mailing lists