Re: [RFCv3 PATCH net-next] net: extend netdev_features_t

[Andrew Lunn <andrew@lunn.ch>]

> > >   static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
> > > diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> > > index 16f778887e14..9b3ab11e19c8 100644
> > > --- a/include/linux/netdev_features.h
> > > +++ b/include/linux/netdev_features.h
> > > @@ -101,12 +101,12 @@ enum {
> > >   typedef struct {
> > >   	DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT);
> > > -} netdev_features_t;
> > > +} netdev_features_t;

> > That hunk looks odd.

> Yes, but it can be return directly, so we don't have to change
> the prototype of functions which return netdev_features_t,
> like  ndo_features_check.
> 
> > > -static inline void netdev_feature_zero(netdev_features_t *dst)
> > > +static inline void netdev_features_zero(netdev_features_t *dst)
> > >   {
> > >   	bitmap_zero(dst->bits, NETDEV_FEATURE_COUNT);
> > >   }
> > > -static inline void netdev_feature_fill(netdev_features_t *dst)
> > > +static inline void netdev_features_fill(netdev_features_t *dst)
> > >   {
> > >   	bitmap_fill(dst->bits, NETDEV_FEATURE_COUNT);
> > >   }
> > I'm wondering that the value here is? What do we gain by added the s.
> > These changes cause a lot of churn in the users of these functions.
> This function is used to expression like below:
> 
> "lowerdev_features &= (features | ~NETIF_F_LRO);"  in drivers/net/macvlan.c

O.K, now i know what is confusing me. This is not a patch on top of
clean net-next/master. It does not have netdev_features_t as a bitmap,
it does not have netdev_feature_fill().

You already have some other changes applied to your tree, and this
patch is on top of that?

I think we generally agree about the direction you are going. What we
probably want to see is a patchset against net-next/master which
converts the core and one driver to this new API. That allows us to
review the new API, which is the important thing here.

>  I prefered to rename the netdev field active_features .

O.K.

	Andrew