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>,
Kuniyuki Iwashima <kuniyu@google.com>,
Ahmed Zaki <ahmed.zaki@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
bridge@lists.linux.dev, linux-kselftest@vger.kernel.org
Subject: Re: [PATCHv2 net-next 5/5] selftests/net: add offload checking test for virtual interface
Date: Tue, 9 Sep 2025 02:54:49 +0000 [thread overview]
Message-ID: <aL-W-YdGWOxgpPar@fedora> (raw)
In-Reply-To: <aL9PSoTwhn-HFWrH@krikkit>
On Mon, Sep 08, 2025 at 11:48:58PM +0200, Sabrina Dubroca wrote:
> > > > After we add the netdevsim to bond,
> > > > the bond also shows "esp-hw-offload off" as the flag is inherit
> > > > in dev->hw_enc_features, not dev->features.
> > >
> > > Did you mean dev->hw_features?
> >
> > No, the xfrm_features in patch 01 updates dev->hw_enc_features, not
> > dev->hw_features.
>
> Ok. But hw_enc_features is not the reason ethtool shows
> "esp-hw-offload off". This line is:
>
> bond_dev->hw_features |= BOND_XFRM_FEATURES;
>
> (from bond_setup)
Ah, there it is. You remind me that I have a bonding xfrm feature patch
not posted yet.
>
> > Do you think if we should update dev->hw_features in the
> > patch?
>
> For dev->hw_features (and dev->features) maybe not, since that depends
> on the upper device's features and implementation. I'm not sure we can
> have a common function without changing the behavior on at least one
> type of device.
>
> But maybe ndo_fix_features could use a common
> netdev_fix_features_from_lowers? bond/team/bridge have very similar
> implementations.
Thanks, will add this to my todo list.
>
> > > > It looks the only way to check if bond dev->hw_enc_features has NETIF_F_HW_ESP
> > > > is try set xfrm offload. As
> > >
> > > Was this test meant to check hw_enc_features?
> > >
> > > To check hw_enc_features, I think the only way would be sending GSO
> > > packets, since it's only used in those situations.
> >
> > Oh.. That would make the test complex. Can we ignore this test first?
>
> Ok for me.
>
> > BTW, I'm a bit lost in the callbacks.gso_segment. e.g.
> >
> > esp4_gso_segment
> > - xfrm4_outer_mode_gso_segment
> > - xfrm4_transport_gso_segment
> > - ops->callbacks.gso_segment
> >
> > But who calls esp4_gso_segment? I can't find where the features is assigned.
>
> inet_gso_segment via inet_offloads[] (ESP is a L4 proto like UDP etc).
Ah, I only saw ipip_gso_segment calls inet_gso_segment, didn't notice
ipv4_offload_init() also init the callback with inet_gso_segment.
Thanks
Hangbin
prev parent reply other threads:[~2025-09-09 2:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 7:25 [PATCHv2 net-next 0/5] net: common feature compute for upper interface Hangbin Liu
2025-09-02 7:25 ` [PATCHv2 net-next 1/5] net: add a common function to compute features from lowers devices Hangbin Liu
2025-09-06 17:42 ` Sabrina Dubroca
2025-09-08 3:20 ` Hangbin Liu
2025-09-07 0:22 ` Jakub Kicinski
2025-09-02 7:25 ` [PATCHv2 net-next 2/5] bonding: use common function to compute the features Hangbin Liu
2025-09-02 7:26 ` [PATCHv2 net-next 3/5] team: " Hangbin Liu
2025-09-02 7:26 ` [PATCHv2 net-next 4/5] net: bridge: " Hangbin Liu
2025-09-02 7:26 ` [PATCHv2 net-next 5/5] selftests/net: add offload checking test for virtual interface Hangbin Liu
2025-09-06 21:30 ` Sabrina Dubroca
2025-09-08 4:15 ` Hangbin Liu
2025-09-08 9:36 ` Sabrina Dubroca
2025-09-08 10:14 ` Hangbin Liu
2025-09-08 21:48 ` Sabrina Dubroca
2025-09-09 2:54 ` Hangbin Liu [this message]
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=aL-W-YdGWOxgpPar@fedora \
--to=liuhangbin@gmail.com \
--cc=ahmed.zaki@intel.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=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sd@queasysnail.net \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
/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.