I am working on fixing the nfacct tests for s390x architecture. The issue arises due to the difference in endianness, where the test data is currently structured for little-endian systems, causing failures on s390x (big-endian).
To address this, I propose generating custom test data specifically for s390x by converting little-endian data to big-endian format. This approach ensures the test cases properly validate behavior on big-endian systems.

Currently, I have a sample patch that fixes two test cases:
valid_with_padding
valid_without_padding

nafcct-s390x.patch.txt

However, many other tests require a similar fix. Before proceeding with a broader solution, I would like to gather feedback from the Kubernetes community regarding this approach.

Is modifying test data per architecture an acceptable approach, or is there a preferred way to handle endianness differences in tests?
Should we introduce a general mechanism for handling such cases, or is it better to patch individual tests as needed?
Are there any existing best practices in the Kubernetes project for handling similar cross-architecture test issues?

I appreciate any input from the community on this matter. Once we agree on an approach, I can extend the fix to other failing tests.

Thanks!