Re: [nft PATCH 22/28] mergesort: Linearize concatentations in network byte order

[Phil Sutter <phil@nwl.cc>]

On Wed, Oct 29, 2025 at 07:27:51PM +0100, Pablo Neira Ayuso wrote:
> On Thu, Oct 23, 2025 at 06:14:11PM +0200, Phil Sutter wrote:
> > Results are more stable this way.
> 
> Why? Sorry, but maybe this series is oversplit? It is a bit complicate
> to follow the rationale where all this small patches are taking us.

TBH, I don't fully understand how all this works internally given that
GMP has its own way of organizing data.

> I find that a single patch with a oneliner explaination.

This change is quite unrelated to others, so folding it into another
patch might have hidden it. I get your point about reviewing 28 patches,
but there is a summary in the cover letter guiding through the series. 

The effects of this patch show in patch 23 which updates the test cases.
I can't tell for sure I didn't cause a big mess wrt. defined byteorder
of strings and dropped/changed byteorder conversions but the resulting
element ordering looks right to me.

> Question: Does tests/shell and tests/py work if I stop at any random
> patch in this series?

Certainly not! I would have to mix code changes and test case updates to
keep test suites passing after each patch. If you like to see what each
patch changes, I can provide a series which does this. I guessed it
would be easier to review if code changes were separate from "noise".

Also maybe worth mentioning explicitly: This series (and the related
libnftnl one) does not intend to contain functional changes and merely
change how libnftnl prints data, apart from two things:

* Set element ordering is changed by this patch

Since nft-test.py explicitly ignores changes in element ordering
I consider this negligible.

* libnftnl stores u32 userdata values in Big Endian

Assuming that the kernel ignores userdata and user space
stores/retrieves it using libnftnl, this should not have a practical
effect (apart from userdata becoming stable).

Cheers, Phil