Re: [PATCH net-next v5 07/22] ethtool: netlink bitset handling

[Michal Kubecek]

On Tue, Mar 26, 2019 at 04:59:11PM +0100, Jiri Pirko wrote:
> Mon, Mar 25, 2019 at 06:08:15PM CET, mkubecek@xxxxxxx wrote:
> >Declare attribute type constants and add helper functions to generate and
> >parse arbitrary length bit sets.
> 
> Hmm, this looks like a lot of work. Two things:
> 1) This is generic. Not really related to ethtool in any way. Could this
>    be done in netlink common code?

I suppose it could if other netlink based APIs would be interested in
using it. The only ethtool specific part is the support for "legacy
style names" (fixed size strings) but that is something I'm not really
happy about.  Perhaps it's time to return to the original idea of
supporting only arrays of (char *) and creating them around existing
fixed size ones.

> 2) Did you think about leveraging NLA_BITFIELD32? What I mean is this:
> NEST_START
>    NLA_BITFIELD32 index 0 (bit 0-31)
>    NLA_BITFIELD32 index 1 (bit 32-63)
>    NLA_BITFIELD32 index 2 (bit 64-95)
>    NLA_BITFIELD32 index 3 (bit 96-127)
>    ....
> NEST_END
> It is basically an array of NLA_BITFIELD32.

That would be similar to compact form but it would introduce the
interleaving and extra struct nlattr header for each block. I don't
think it would make things easier.

The verbose form is meant to allow requests like

  ethtool -K eth0 tx-vlan-stag-hw-insert on
  ethtool -s eth0 advertise 1000baseT/Full off

without either keeping the table of available flags in sync between
kernel and userspace (all userspace users of the API) or having to ask
for the list first (in case of one shot requests as above; long running
tools like "ethtool --monitor" or config management daemons would keep
the tables and use compact form).

Michal