netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Lobakin <alexandr.lobakin@intel.com>
To: "shenjian (K)" <shenjian15@huawei.com>
Cc: Alexander Lobakin <alexandr.lobakin@intel.com>,
	davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
	ecree.xilinx@gmail.com, hkallweit1@gmail.com, saeed@kernel.org,
	leon@kernel.org, netdev@vger.kernel.org, linuxarm@openeuler.org
Subject: Re: [RFCv7 PATCH net-next 36/36] net: redefine the prototype of netdev_features_t
Date: Thu, 11 Aug 2022 15:07:57 +0200	[thread overview]
Message-ID: <20220811130757.9904-1-alexandr.lobakin@intel.com> (raw)
In-Reply-To: <3df89822-7dec-c01e-0df9-15b8e6f7d4e5@huawei.com>

From: "shenjian (K)" <shenjian15@huawei.com>
Date: Wed, 10 Aug 2022 21:34:43 +0800

BTW, you replied in HTML instead of plain text and korg mail servers
rejected it. So non-Ccs can't see it. Just be aware that LKML
accepts plain text only :)

> 在 2022/8/10 19:35, Alexander Lobakin 写道:
> > From: Jian Shen <shenjian15@huawei.com>
> > Date: Wed, 10 Aug 2022 11:06:24 +0800
> >
> >> For the prototype of netdev_features_t is u64, and the number
> >> of netdevice feature bits is 64 now. So there is no space to
> >> introduce new feature bit. Change the prototype of netdev_features_t
> >> from u64 to structure below:
> >> 	typedef struct {
> >> 		DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT);
> >> 	} netdev_features_t;
> >>
> >> Rewrite the netdev_features helpers to adapt with new prototype.
> >>
> >> To avoid mistake using NETIF_F_XXX as NETIF_F_XXX_BIT as
> >> input macroes for above helpers, remove all the macroes
> >> of NETIF_F_XXX for single feature bit. Serveal macroes remained
> >> temporarily, by some precompile dependency.
> >>
> >> With the prototype is no longer u64, the implementation of print
> >> interface for netdev features(%pNF) is changed to bitmap. So
> >> does the implementation of net/ethtool/.
> >>
> >> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> >> ---
> >>   drivers/net/ethernet/amazon/ena/ena_netdev.c  |  12 +-
> >>   .../net/ethernet/intel/i40e/i40e_debugfs.c    |  12 +-
> >>   .../ethernet/netronome/nfp/nfp_net_common.c   |   4 +-
> >>   .../net/ethernet/pensando/ionic/ionic_lif.c   |   4 +-
> >>   include/linux/netdev_features.h               | 101 ++----------
> >>   include/linux/netdev_features_helper.h        | 149 +++++++++++-------
> >>   include/linux/netdevice.h                     |   7 +-
> >>   include/linux/skbuff.h                        |   4 +-
> >>   include/net/ip_tunnels.h                      |   2 +-
> >>   lib/vsprintf.c                                |  11 +-
> >>   net/ethtool/features.c                        |  96 ++++-------
> >>   net/ethtool/ioctl.c                           |  46 ++++--
> >>   net/mac80211/main.c                           |   3 +-
> >>   13 files changed, 201 insertions(+), 250 deletions(-)
> > [...]
> >
> >> -static inline int find_next_netdev_feature(u64 feature, unsigned long start)
> >> -{
> >> -	/* like BITMAP_LAST_WORD_MASK() for u64
> >> -	 * this sets the most significant 64 - start to 0.
> >> -	 */
> >> -	feature &= ~0ULL >> (-start & ((sizeof(feature) * 8) - 1));
> >> -
> >> -	return fls64(feature) - 1;
> >> -}
> >> +#define NETIF_F_HW_VLAN_CTAG_TX
> >> +#define NETIF_F_IPV6_CSUM
> >> +#define NETIF_F_TSO
> >> +#define NETIF_F_GSO
> > Uhm, what are those empty definitions for? They look confusing.
> I kept them temporary for some drivers use them like below:
> for example in drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> #ifdef NETIF_F_HW_VLAN_CTAG_TX
> #include <linux/if_vlan.h>
> #endif
> 
> So far I haven't got a good way to replace it.

I believe such constructs sneaked in from some development/draft
versions of the code, as those definitions are always here, so
this is just redundant/pointless.
Just remove those ifdefs and always include the file.
The empty definitions you left in netdev_features.h are confusing,
I'd not keep them.

> 
> >>   
> >>   /* This goes for the MSB to the LSB through the set feature bits,
> >>    * mask_addr should be a u64 and bit an int
> >>    */

[...]

> >> +#define GSO_ENCAP_FEATURES	(((u64)1 << NETIF_F_GSO_GRE_BIT) |		\
> >> +				 ((u64)1 << NETIF_F_GSO_GRE_CSUM_BIT) |		\
> >> +				 ((u64)1 << NETIF_F_GSO_IPXIP4_BIT) |		\
> >> +				 ((u64)1 << NETIF_F_GSO_IPXIP6_BIT) |		\
> >> +				 (((u64)1 << NETIF_F_GSO_UDP_TUNNEL_BIT) |	\
> >> +				  ((u64)1 << NETIF_F_GSO_UDP_TUNNEL_CSUM_BIT)))
> > 1) 1ULL;
> ok,will fix it
> 
> > 2) what if we get a new GSO encap type which's bit will be higher
> >     than 64?
> So far I prefer to use this.  It's used to assgned to 
> skb_shinfo(skb)->gso_type, which prototype
> is 'unsigned int'.  Once new gso encap type introduced, we should extend 
> the gso_type first.

But ::gso_type accepts flags like %SKB_GSO_DODGY and so on, not
netdev_features, doesn't it?

> 
> 
> >> +
> >>   #endif	/* _LINUX_NETDEV_FEATURES_H */

[...]

> >>   static inline netdev_features_t
> >>   netdev_features_and(const netdev_features_t a, const netdev_features_t b)
> >>   {
> >> -	return a & b;
> >> +	netdev_features_t dst;
> >> +
> >> +	bitmap_and(dst.bits, a.bits, b.bits, NETDEV_FEATURE_COUNT);
> >> +	return dst;
> > Yeah, so as I wrote previously, not a good idea to return a whole
> > bitmap/structure.
> >
> > netdev_features_and(*dst, const *a, const *b)
> > {
> > 	return bitmap_and(); // bitmap_and() actually returns useful value
> > }
> >
> > I mean, 16 bytes (currently 8, but some new features will come
> > pretty shortly, I'm sure) are probably okayish, but... let's see
> > what other folks think, but even Linus wrote about this recently
> > BTW.
> Yes, Jakub also mentioned this.
> 
> But there are many existed features interfaces(e.g. ndo_fix_features,
> ndo_features_check), use netdev_features_t as return value. Then we
> have to change their prototype.

We have to do 12k lines of changes already :D
You know, 16 bytes is probably fine to return directly and it will
be enough for up to 128 features (+64 more comparing to the
mainline). OTOH, using pointers removes that "what if/when", so
it's more flexible in that term. So that's why I asked for other
folks' opinions -- 2 PoVs doesn't seem enough here.

> 
> second problem is for the helpers' definition. For example:
> When we introduce helper like netdev_features_zero(netdev_features_t 
> *features)
> without change prototype of netdev_features_t.
> once covert netdev_features_t from u64 to unsigned long *, then it becomes
> netdev_features_zero(unsigned long **features), result in much redundant 
> work
> to adjust it to netdev_features_zero(unsigned long *features).

> 
> 
> >>   }

[...]

> >>   static noinline_for_stack
> >> -char *netdev_bits(char *buf, char *end, const void *addr,
> >> +char *netdev_bits(char *buf, char *end, void *addr,
> >>   		  struct printf_spec spec,  const char *fmt)
> >>   {
> >> -	unsigned long long num;
> >> -	int size;
> >> +	netdev_features_t *features;
> > const? We're printing.
> It will cause compile warning for bitmap_string use features->bits
> as input param without "const" definition in its prototype.

Oof, that's weird. I checked the function you mentioned and don't
see any reason why it would require non-RO access to the bitmap it
prints.
Could you maybe please change its proto to take const bitmap, so
that it won't complain on your code? As a separate patch going right
before this one in your series.

> >>   
> >>   	if (check_pointer(&buf, end, addr, spec))
> >>   		return buf;
> >>   
> >>   	switch (fmt[1]) {
> >>   	case 'F':
> >> -		num = *(const netdev_features_t *)addr;
> >> -		size = sizeof(netdev_features_t);
> >> +		features = (netdev_features_t *)addr;
> > Casts are not needed when assigning from `void *`.
> ok, will fix it
> >> +		spec.field_width = NETDEV_FEATURE_COUNT;
> >>   		break;
> >>   	default:
> >>   		return error_string(buf, end, "(%pN?)", spec);
> >>   	}
> >>   
> >> -	return special_hex_number(buf, end, num, size);
> >> +	return bitmap_string(buf, end, features->bits, spec, fmt);
> >>   }

[...]

> >> -- 
> >> 2.33.0
> > That's my last review email for now. Insane amount of work, I'm glad
> > someone did it finally. Thanks a lot!
> >
> > Olek
> > .
> Hi   Olek,
> Grateful for your review.  You made a lot of valuable suggestions. I will
> check and continue refine the patchset.
> 
> Thanks again!
> 
> Jian

Thanks!
Olek

  parent reply	other threads:[~2022-08-11 13:09 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10  3:05 [RFCv7 PATCH net-next 00/36] net: extend the type of netdev_features_t to bitmap Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 01/36] net: introduce operation helpers for netdev features Jian Shen
2022-08-10  9:43   ` Alexander Lobakin
2022-08-10 11:32     ` shenjian (K)
2022-08-11 10:49       ` Alexander Lobakin
2022-08-12  2:39         ` shenjian (K)
2022-08-10  3:05 ` [RFCv7 PATCH net-next 02/36] net: replace general features macroes with global netdev_features variables Jian Shen
2022-08-10  9:58   ` Alexander Lobakin
2022-08-10 12:01     ` shenjian (K)
2022-08-11 11:05       ` Alexander Lobakin
2022-08-12 10:58         ` shenjian (K)
2022-08-10  3:05 ` [RFCv7 PATCH net-next 03/36] net: replace multiple feature bits with DECLARE_NETDEV_FEATURE_SET Jian Shen
2022-08-10 10:37   ` Alexander Lobakin
2022-08-10 12:15     ` shenjian (K)
2022-08-10  3:05 ` [RFCv7 PATCH net-next 04/36] net: sfc: replace const features initialization " Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 05/36] net: atlantic: replace const features initialization with NETDEV_FEATURE_SET Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 06/36] iwlwifi: " Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 07/36] net: ethernet: mtk_eth_soc: " Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 08/36] ravb: " Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 09/36] test_bpf: " Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 10/36] treewide: replace NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK by netdev_csum_gso_features_mask Jian Shen
2022-08-10  3:05 ` [RFCv7 PATCH net-next 11/36] treewide: replace NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM by netdev_ip_csum_features Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 12/36] treewide: replace NETIF_F_TSO | NETIF_F_TSO6 by netdev_general_tso_features Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 13/36] treewide: replace VLAN tag feature array by const vlan features Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 14/36] net: simplify the netdev features expressions for xxx_gso_segment Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 15/36] treewide: simplify the netdev features expression Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 16/36] treewide: use replace features '0' by netdev_empty_features Jian Shen
2022-08-10 10:48   ` Alexander Lobakin
2022-08-10 12:25     ` shenjian (K)
2022-08-11 12:35       ` Alexander Lobakin
2022-08-10  3:06 ` [RFCv7 PATCH net-next 17/36] treewide: adjust features initialization Jian Shen
2022-08-10 10:58   ` Alexander Lobakin
2022-08-10 14:06     ` shenjian (K)
2022-08-10  3:06 ` [RFCv7 PATCH net-next 18/36] net: mlx4: adjust the net device feature relative macroes Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 19/36] net: mlx5e: adjust " Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 20/36] net: mlxsw: adjust input parameter for function mlxsw_sp_handle_feature Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 21/36] net: iavf: adjust net device features relative macroes Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 22/36] net: core: adjust netdev_sync_xxx_features Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 23/36] net: adjust the build check for net_gso_ok() Jian Shen
2022-08-10 11:09   ` Alexander Lobakin
2022-08-10 14:41     ` shenjian (K)
2022-08-10  3:06 ` [RFCv7 PATCH net-next 24/36] treewide: use netdev_feature_add helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 25/36] treewide: use netdev_features_or/set helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 26/36] treewide: use netdev_feature_change helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 27/36] treewide: use netdev_feature_del helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 28/36] treewide: use netdev_features_andnot and netdev_features_clear helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 29/36] treewide: use netdev_features_xor helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 30/36] treewide: use netdev_feature_test helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 31/36] treewide: use netdev_features_intersects helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 32/36] net: use netdev_features_and and netdev_features_mask helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 33/36] treewide: use netdev_features_subset helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 34/36] treewide: use netdev_features_equal helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 35/36] treewide: use netdev_features_empty helpers Jian Shen
2022-08-10  3:06 ` [RFCv7 PATCH net-next 36/36] net: redefine the prototype of netdev_features_t Jian Shen
2022-08-10 11:35   ` Alexander Lobakin
     [not found]     ` <3df89822-7dec-c01e-0df9-15b8e6f7d4e5@huawei.com>
2022-08-11 13:07       ` Alexander Lobakin [this message]
2022-08-11 15:13         ` Jakub Kicinski
2022-08-12 11:43           ` shenjian (K)
2022-08-12 11:30         ` shenjian (K)

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=20220811130757.9904-1-alexandr.lobakin@intel.com \
    --to=alexandr.lobakin@intel.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=ecree.xilinx@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=netdev@vger.kernel.org \
    --cc=saeed@kernel.org \
    --cc=shenjian15@huawei.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;
as well as URLs for NNTP newsgroup(s).