Re: [PATCH net-next v8 03/14] ethtool: netlink bitset handling

[Florian Fainelli]

On 12/22/2019 3:45 PM, Michal Kubecek wrote:
> The ethtool netlink code uses common framework for passing arbitrary
> length bit sets to allow future extensions. A bitset can be a list (only
> one bitmap) or can consist of value and mask pair (used e.g. when client
> want to modify only some bits). A bitset can use one of two formats:
> verbose (bit by bit) or compact.
> 
> Verbose format consists of bitset size (number of bits), list flag and
> an array of bit nests, telling which bits are part of the list or which
> bits are in the mask and which of them are to be set. In requests, bits
> can be identified by index (position) or by name. In replies, kernel
> provides both index and name. Verbose format is suitable for "one shot"
> applications like standard ethtool command as it avoids the need to
> either keep bit names (e.g. link modes) in sync with kernel or having to
> add an extra roundtrip for string set request (e.g. for private flags).
> 
> Compact format uses one (list) or two (value/mask) arrays of 32-bit
> words to store the bitmap(s). It is more suitable for long running
> applications (ethtool in monitor mode or network management daemons)
> which can retrieve the names once and then pass only compact bitmaps to
> save space.
> 
> Userspace requests can use either format; ETHTOOL_FLAG_COMPACT_BITSETS
> flag in request header tells kernel which format to use in reply.
> Notifications always use compact format.
> 
> As some code uses arrays of unsigned long for internal representation and
> some arrays of u32 (or even a single u32), two sets of parse/compose
> helpers are introduced. To avoid code duplication, helpers for unsigned
> long arrays are implemented as wrappers around helpers for u32 arrays.
> There are two reasons for this choice: (1) u32 arrays are more frequent in
> ethtool code and (2) unsigned long array can be always interpreted as an
> u32 array on little endian 64-bit and all 32-bit architectures while we
> would need special handling for odd number of u32 words in the opposite
> direction.
> 
> Signed-off-by: Michal Kubecek <mkubecek@xxxxxxx>

Reviewed-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
-- 
Florian