From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Masahiro Yamada <masahiroy@kernel.org>,
netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH net-next v9 03/10] lib: packing: add pack_fields() and unpack_fields()
Date: Thu, 5 Dec 2024 12:15:01 +0200 [thread overview]
Message-ID: <20241205101501.ufmixuzon7a2cnam@skbuf> (raw)
In-Reply-To: <20241204-packing-pack-fields-and-ice-implementation-v9-3-81c8f2bd7323@intel.com> <20241204-packing-pack-fields-and-ice-implementation-v9-3-81c8f2bd7323@intel.com>
On Wed, Dec 04, 2024 at 05:22:49PM -0800, Jacob Keller wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> This is new API which caters to the following requirements:
>
> - Pack or unpack a large number of fields to/from a buffer with a small
> code footprint. The current alternative is to open-code a large number
> of calls to pack() and unpack(), or to use packing() to reduce that
> number to half. But packing() is not const-correct.
>
> - Use unpacked numbers stored in variables smaller than u64. This
> reduces the rodata footprint of the stored field arrays.
>
> - Perform error checking at compile time, rather than runtime, and return
> void from the API functions. Because the C preprocessor can't generate
> variable length code (loops), this is a bit tricky to do with macros.
>
> To handle this, implement macros which sanity check the packed field
> definitions based on their size. Finally, a single macro with a chain of
> __builtin_choose_expr() is used to select the appropriate macros. We
> enforce the use of ascending or descending order to avoid O(N^2) scaling
> when checking for overlap. Note that the macros are written with care to
> ensure that the compilers can correctly evaluate the resulting code at
> compile time. In particular, care was taken with avoiding too many nested
> statement expressions. Nested statement expressions trip up some
> compilers, especially when passing down variables created in previous
> statement expressions.
>
> There are two key design choices intended to keep the overall macro code
> size small. First, the definition of each CHECK_PACKED_FIELDS_N macro is
> implemented recursively, by calling the N-1 macro. This avoids needing
> the code to repeat multiple times.
>
> Second, the CHECK_PACKED_FIELD macro enforces that the fields in the
> array are sorted in order. This allows checking for overlap only with
> neighboring fields, rather than the general overlap case where each field
> would need to be checked against other fields.
>
> The overlap checks use the first two fields to determine the order of the
> remaining fields, thus allowing either ascending or descending order.
> This enables drivers the flexibility to keep the fields ordered in which
> ever order most naturally fits their hardware design and its associated
> documentation.
>
> The CHECK_PACKED_FIELDS macro is directly called from within pack_fields
> and unpack_fields, ensuring that all drivers using the API receive the
> benefits of the compile-time checks. Users do not need to directly call
> any of the macros directly.
>
> The CHECK_PACKED_FIELDS and its helper macros CHECK_PACKED_FIELDS_(0..50)
> are generated using a simple C program in scripts/gen_packed_field_checks.c
> This program can be compiled on demand and executed to generate the macro
> code in include/linux/packing.h. This will aid in the event that a driver
> needs more than 50 fields. The generator can be updated with a new size,
> and used to update the packing.h header file. In practice, the ice driver
> will need to support 27 fields, and the sja1105 driver will need to
> support 40 fields. This on-demand generation avoids the need to modify
> Kbuild. We do not anticipate the maximum number of fields to grow very
> often.
>
> - Reduced rodata footprint for the storage of the packed field arrays.
> To that end, we have struct packed_field_s (small) and packed_field_m
> (medium). More can be added as needed (unlikely for now). On these
> types, the same generic pack_fields() and unpack_fields() API can be
> used, thanks to the new C11 _Generic() selection feature, which can
> call pack_fields_s() or pack_fields_m(), depending on the type of the
> "fields" array - a simplistic form of polymorphism. It is evaluated at
> compile time which function will actually be called.
>
> Over time, packing() is expected to be completely replaced either with
> pack() or with pack_fields().
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Co-developed-by: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> # KUnit
next prev parent reply other threads:[~2024-12-05 10:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 1:22 [PATCH net-next v9 00/10] lib: packing: introduce and use (un)pack_fields Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 01/10] lib: packing: create __pack() and __unpack() variants without error checking Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 02/10] lib: packing: demote truncation error in pack() to a warning in __pack() Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 03/10] lib: packing: add pack_fields() and unpack_fields() Jacob Keller
2024-12-05 10:15 ` Vladimir Oltean [this message]
2024-12-09 22:18 ` Jakub Kicinski
2024-12-09 23:05 ` Jacob Keller
2024-12-10 10:59 ` Vladimir Oltean
2024-12-10 20:10 ` Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 04/10] lib: packing: document recently added APIs Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 05/10] ice: remove int_q_state from ice_tlan_ctx Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 06/10] ice: use structures to keep track of queue context size Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 07/10] ice: use <linux/packing.h> for Tx and Rx queue context data Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 08/10] ice: reduce size of queue context fields Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 09/10] ice: move prefetch enable to ice_setup_rx_ctx Jacob Keller
2024-12-05 1:22 ` [PATCH net-next v9 10/10] ice: cleanup Rx queue context programming functions Jacob Keller
2024-12-05 10:20 ` [PATCH net-next v9 00/10] lib: packing: introduce and use (un)pack_fields Vladimir Oltean
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=20241205101501.ufmixuzon7a2cnam@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=akpm@linux-foundation.org \
--cc=anthony.l.nguyen@intel.com \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=masahiroy@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.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