From: Paolo Abeni <pabeni@redhat.com>
To: Hangbin Liu <liuhangbin@gmail.com>, 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>, 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, linux-kselftest@vger.kernel.org
Subject: Re: [PATCHv3 net-next 5/5] selftests/net: add offload checking test for virtual interface
Date: Thu, 11 Sep 2025 17:41:24 +0200 [thread overview]
Message-ID: <cd37574b-0c15-481d-84dd-8ccc830efd06@redhat.com> (raw)
In-Reply-To: <aMJyC_YNjVWcB7pe@fedora>
On 9/11/25 8:54 AM, Hangbin Liu wrote:
> On Wed, Sep 10, 2025 at 04:57:54PM +0200, Sabrina Dubroca wrote:
>> 2025-09-09, 08:18:52 +0000, Hangbin Liu wrote:
>>> +__check_offload()
>>> +{
>>> + local dev=$1
>>> + local opt=$2
>>> + local expect=$3
>>> +
>>> + ip netns exec "$ns" ethtool --json -k "$dev" | \
>>> + jq -r -e ".[].\"$opt\".active == ${expect}" >/dev/null
>>
>> Sorry Hangbin, I should have noticed this when we discussed the IPsec
>> test, since the problem is similar for the other features set in
>> netdev_compute_features_from_lowers:
>>
>> `ethtool -k` does not test the dev->*_features (mpls, vlan, etc) set
>> in the new common function, it only checks dev->features and
>> dev->hw_features. So this will not test the new function.
>
> Hmm, that make the selftest more complex. A very easy way to verify whether
> the feature is set is using tracepoint. But Paolo said adding new tracepoint
> is not welcomed.
>
> Since all these flags are fixed after compute from lower devices. We need to
> find out a proper device and test the features are inherited.
>
> The next question is how to test gso_partial_features, vlan_features,
> hw_enc_features, mpls_features (maybe also tso_max_segs/size in future)
> effectively.
>
> The veth device only has hw_enc_features and mpls_features, while it's
> hw_enc_features doesn't have NETIF_F_HW_ESP. The netdevsim device only have
> hw_enc_features.
>
>
> For mpls_features, seem we only able to test NETIF_F_GSO_SOFTWARE, but I'm not
> sure how to check mpls gso..
>
> For hw_enc_features NETIF_F_HW_ESP. Does sending ipsec data and see if
> netdevsim has pkts count enough??
>
> Any advices? Should we just drop the selftest?
Uhm... one possible way of testing netdev_compute_features_from_lowers()
correctness is transmitting over the relevant device (bridge/team/bond)
"arbitrary" GSO packets and verify that the packet is segmented (or not)
before reaching the lower.
GSO packet injection can be done with some work via the tun device (in
tap mode), and the virtio hdr.
That is limited to some GSO types (i.e. no ipsec pkts), and can become
easily very complex.
What about giving it a shot for UDP tunnel GSO types?
Thanks,
Paolo
next prev parent reply other threads:[~2025-09-11 15:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 8:18 [PATCHv3 net-next 0/5] net: common feature compute for upper interface Hangbin Liu
2025-09-09 8:18 ` [PATCHv3 net-next 1/5] net: add a common function to compute features from lowers devices Hangbin Liu
2025-09-09 8:18 ` [PATCHv3 net-next 2/5] bonding: use common function to compute the features Hangbin Liu
2025-09-09 8:18 ` [PATCHv3 net-next 3/5] team: " Hangbin Liu
2025-09-10 15:31 ` Stanislav Fomichev
2025-09-11 1:46 ` Hangbin Liu
2025-09-09 8:18 ` [PATCHv3 net-next 4/5] net: bridge: " Hangbin Liu
2025-09-09 8:18 ` [PATCHv3 net-next 5/5] selftests/net: add offload checking test for virtual interface Hangbin Liu
2025-09-10 14:57 ` Sabrina Dubroca
2025-09-11 6:54 ` Hangbin Liu
2025-09-11 15:41 ` Paolo Abeni [this message]
2025-09-12 6:52 ` Hangbin Liu
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=cd37574b-0c15-481d-84dd-8ccc830efd06@redhat.com \
--to=pabeni@redhat.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=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox