Netdev List
 help / color / mirror / Atom feed
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

  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