All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Hangbin Liu <liuhangbin@gmail.com>
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: Mon, 20 Oct 2025 11:10:14 +0200	[thread overview]
Message-ID: <aPX8di8QX96JvIZY@krikkit> (raw)
In-Reply-To: <20251017034155.61990-2-liuhangbin@gmail.com>

2025-10-17, 03:41:52 +0000, Hangbin Liu wrote:
> Some high level software drivers need to compute features from lower
> devices. But each has their own implementations and may lost some
> feature compute. Let's use one common function to compute features
> for kinds of these devices.
> 
> The new helper uses the current bond implementation as the reference
> one, as the latter already handles all the relevant aspects: netdev
> features, TSO limits and dst retention.
> 
> Suggested-by: Paolo Abeni <pabeni@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>

No objection to this patch/series, just a nit and some discussion below, so:

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>


[...]
> +/**
> + *	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).

> + *	@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]

?


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)

> +}

-- 
Sabrina

  reply	other threads:[~2025-10-20  9:10 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 [this message]
2025-10-21  4:03     ` Hangbin Liu
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=aPX8di8QX96JvIZY@krikkit \
    --to=sd@queasysnail.net \
    --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=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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.