All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: Sabrina Dubroca <sd@queasysnail.net>
Cc: netdev@vger.kernel.org, Jay Vosburgh <jv@jvosburgh.net>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Jiri Pirko <jiri@resnulli.us>, Simon Horman <horms@kernel.org>,
	Ido Schimmel <idosch@nvidia.com>, Shuah Khan <shuah@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Stanislav Fomichev <stfomichev@gmail.com>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	bridge@lists.linux.dev
Subject: Re: [PATCHv6 net-next 1/4] net: add a common function to compute features for upper devices
Date: Tue, 21 Oct 2025 04:03:31 +0000	[thread overview]
Message-ID: <aPcGE36U9DSza8xU@fedora> (raw)
In-Reply-To: <aPX8di8QX96JvIZY@krikkit>

On Mon, Oct 20, 2025 at 11:10:14AM +0200, Sabrina Dubroca wrote:
> > +/**
> > + *	netdev_compute_master_upper_features - compute feature from lowers
> 
> nit: I'm slightly annoyed (that's not quite the right word, sorry)
> that we're adding a new function to "compute features" that doesn't
> touch netdev->features, but I can't come up with a better name
> (the best I got was "compute extra features" and it doesn't help).

Ah, yes, the term "compute features" can be confusing since we don’t actually
 update netdev->features. We can rename it if there’s a better alternative.

> 
> > + *	@dev: the upper device
> > + *	@update_header: whether to update upper device's header_len/headroom/tailroom
> > + *
> > + *	Recompute the upper device's feature based on all lower devices.
> > + */
> > +void netdev_compute_master_upper_features(struct net_device *dev, bool update_header)
> > +{
> [...]
> > +	netif_set_tso_max_segs(dev, tso_max_segs);
> > +	netif_set_tso_max_size(dev, tso_max_size);
> > +
> > +	netdev_change_features(dev);
> 
> Maybe a dumb idea: I'm wondering if we're doing this from the wrong
> side.
> 
> Right now we have:
> 
> [some device op] -> [this new function] -> netdev_change_features -> __netdev_update_features -> ndo_fix_features
> 
> Would it make more sense to go instead:
> 
> [some device op] -> netdev_change_features -> __netdev_update_features -> ndo_fix_features -> [this new function]

Since we actually doesn't touch netdev->feature. I think [this new function]
and netdev_change_features() should be in parallel relationship.

> 
> Possible benefit: not forgetting to fix up the "extra" features in
> some cases?  (ie calling netdev_change_features when we should have
> called netdev_compute_master_upper_features)

That’s a good reason to call them together. However, ndo_fix_features is used
for computing new features for later use. Since we both compute and set them,
maybe we should put this in ndo_set_features instead?

Thanks
Hangbin

  reply	other threads:[~2025-10-21  4:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-17  3:41 [PATCHv6 net-next 0/4] net: common feature compute for upper interface Hangbin Liu
2025-10-17  3:41 ` [PATCHv6 net-next 1/4] net: add a common function to compute features for upper devices Hangbin Liu
2025-10-20  9:10   ` Sabrina Dubroca
2025-10-21  4:03     ` Hangbin Liu [this message]
2025-10-21  8:46     ` Paolo Abeni
2025-10-21 10:05       ` Hangbin Liu
2025-10-21 16:52       ` Sabrina Dubroca
2025-10-17  3:41 ` [PATCHv6 net-next 2/4] bonding: use common function to compute the features Hangbin Liu
2025-10-20  9:10   ` Sabrina Dubroca
2025-10-17  3:41 ` [PATCHv6 net-next 3/4] team: " Hangbin Liu
2025-10-20  9:11   ` Sabrina Dubroca
2025-10-17  3:41 ` [PATCHv6 net-next 4/4] net: bridge: " Hangbin Liu
2025-10-20  9:17   ` Sabrina Dubroca
2025-10-17  9:58 ` [PATCHv6 net-next 0/4] net: common feature compute for upper interface Jiri Pirko
2025-10-22  1:30 ` patchwork-bot+netdevbpf

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=aPcGE36U9DSza8xU@fedora \
    --to=liuhangbin@gmail.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bridge@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --cc=jv@jvosburgh.net \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=stfomichev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.