netdev - Re: [RFC net-next 1/4] doc/netlink: Add batch op definitions to netlink-raw schema

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2zfvlluhz.fsf@gmail.com>
Date: Tue, 27 Feb 2024 16:52:40 +0000
From: Donald Hunter <donald.hunter@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org,  "David S. Miller" <davem@...emloft.net>,  Eric
 Dumazet <edumazet@...gle.com>,  Paolo Abeni <pabeni@...hat.com>,  Jacob
 Keller <jacob.e.keller@...el.com>,  Jiri Pirko <jiri@...nulli.us>,
  Stanislav Fomichev <sdf@...gle.com>,  donald.hunter@...hat.com
Subject: Re: [RFC net-next 1/4] doc/netlink: Add batch op definitions to
 netlink-raw schema

Jakub Kicinski <kuba@...nel.org> writes:

> On Sun, 25 Feb 2024 17:46:16 +0000 Donald Hunter wrote:
>> The nftables netlink families use batch operations for create update and
>> delete operations. Extend the netlink-raw schema so that operations can
>> be marked as batch ops. Add definitions of the begin-batch and end-batch
>> messages.
>> 
>> The begin/end messages themselves are defined as ordinary ops, but there
>> are new attributes that describe the op name and parameters for the
>> begin/end messages.
>> 
>> The section of yaml spec that defines the begin/end ops looks like this;
>> the newtable op is marked 'is-batch: true' so the message needs to be
>> wrapped with 'batch-begin(res-id: 10)' and batch-end(res-id: 10) messages:
>
> I'm not familiar with nftables nl. Can you explain what the batch ops
> are for and how they function?
>
> Begin / end makes it sound like some form of a transaction, is it?

Yes, it's handled as a transaction, containing multiple messages wrapped
in BATCH_BEGIN / BATCH_END in a single skb.

The transaction batching could be implemented without any schema changes
by just adding multi-message capability to ynl. Then it would be the
caller's responsibility to specify the right begin / end messages.