Linux kbuild/kconfig development
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Vladimir Oltean <olteanv@gmail.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>,
	netdev <netdev@vger.kernel.org>, <linux-kbuild@vger.kernel.org>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [PATCH net-next v5 3/9] lib: packing: add pack_fields() and unpack_fields()
Date: Wed, 13 Nov 2024 13:04:16 -0800	[thread overview]
Message-ID: <5a666ac7-4026-4d4f-b2dc-74a124055f21@intel.com> (raw)
In-Reply-To: <CAK7LNARAsyOparQ1YxgPh9S4A-uzF04k+91t7Xy1jdTy6uT+Vg@mail.gmail.com>



On 11/13/2024 12:32 PM, Masahiro Yamada wrote:
> On Mon, Nov 11, 2024 at 5:08 PM Jacob Keller <jacob.e.keller@intel.com> 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 generat
>>   variable length code (loops), we can't easily use macros to implement the
>>   overlap checks at compile time.
>>
>>   Instead, check for field ordering and overlap in modpost.
> 
> This is over-engineering.
> 
> modpost should not be bothered just for a small library like this.
> 
> Please do sanity checks within lib/packing.c
> 

With the goal of maintaining compile time checks, we end up either
needing to use generated macros which are O(N^2) if we allow arbitrary
overlap. If we instead allow only only ascending or descending order,
this would drop to O(N) which would avoid needing to have 20k lines of
generated code for the case with 50. I think we could implement them
without forcing drivers to specifically call the correct macro by using
something like __builtin_choose_expr(), tho implementing that macro to
select could be quite long.

Otherwise we can fall back to either module load time checks, or go all
the way back to only sanity checking at executing of pack_fields or
unpack_fields.

  reply	other threads:[~2024-11-13 21:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11  8:08 [PATCH net-next v5 0/9] lib: packing: introduce and use (un)pack_fields Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 1/9] lib: packing: create __pack() and __unpack() variants without error checking Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 2/9] lib: packing: demote truncation error in pack() to a warning in __pack() Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 3/9] lib: packing: add pack_fields() and unpack_fields() Jacob Keller
2024-11-11 10:25   ` kernel test robot
2024-11-11 10:36   ` kernel test robot
2024-11-13 20:32   ` Masahiro Yamada
2024-11-13 21:04     ` Jacob Keller [this message]
2024-11-15 20:48       ` Masahiro Yamada
2024-11-15 23:44         ` Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 4/9] ice: remove int_q_state from ice_tlan_ctx Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 5/9] ice: use structures to keep track of queue context size Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 6/9] ice: use <linux/packing.h> for Tx and Rx queue context data Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 7/9] ice: reduce size of queue context fields Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 8/9] ice: move prefetch enable to ice_setup_rx_ctx Jacob Keller
2024-11-11  8:08 ` [PATCH net-next v5 9/9] ice: cleanup Rx queue context programming functions Jacob Keller

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=5a666ac7-4026-4d4f-b2dc-74a124055f21@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=vladimir.oltean@nxp.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