Re: [RFC PATCH net-next 0/7] 802.1Q Frame Preemption and 802.3 MAC Merge support via ethtool

[Jakub Kicinski <kuba@kernel.org>]

On Sat, 1 Oct 2022 15:53:38 +0000 Vladimir Oltean wrote:
> > Add a attribute to ETHTOOL_MSG_STATS_GET, let's call it
> > ETHTOOL_A_STATS_EXPRESS, a flag.  
> 
> I'll add this to the UAPI and to internal data structures, ok?
> 
> enum ethtool_stats_src {
> 	ETHTOOL_STATS_SRC_AGGREGATE = 0,
> 	ETHTOOL_STATS_SRC_EMAC,
> 	ETHTOOL_STATS_SRC_PMAC,
> };

Yup!

> > Plumb thru to all the stats callback an extra argument 
> > (a structure for future extensibility) with a bool pMAC;
> > 
> > Add a capability field to ethtool_ops to announce that
> > driver will pay attention to the bool pMAC / has support.  
> 
> You mean capability field as in ethtool_ops::supported_coalesce_params,
> right? (we discussed about this separately).
> This won't fit the enetc driver very well. Some enetc ports on the NXP
> LS1028A support the MM layer (port 0, port 2) and some don't (port 1,
> port 3). Yet they share the same PF driver. So populating mm_supported =
> true in the const struct enetc_pf_ethtool_ops isn't going to cover both.
> I can, however, key on my ethtool_ops :: get_mm_state() function which
> lets the driver report a "bool supported". Is this ok?

That happens, I think about the capability in the ops as driver caps
rather than HW caps. The driver can still return -EOPNOTSUPP, but it
guarantees to check the field's value. 

Most (all but one) datacenter NIC vendors have uber-drivers for all
their HW generations these days, static per-driver caps can't map to 
HW caps in my world.

So weak preference for sticking to that model to avoid confusion about
the semantics of existing caps vs caps which should use a function call.