From: Benjamin Poirier <benjamin.poirier@gmail.com>
To: Liang Chen <liangchen.linux@gmail.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org
Subject: Re: [RFC PATCH net-next] pktgen: Introducing a parameter for non-shared skb testing
Date: Wed, 6 Sep 2023 18:32:17 -0400 [thread overview]
Message-ID: <ZPj98UXjJdsEsVJQ@d3> (raw)
In-Reply-To: <20230906103508.6789-1-liangchen.linux@gmail.com>
On 2023-09-06 18:35 +0800, Liang Chen wrote:
> Currently, skbs generated by pktgen always have their reference count
> incremented before transmission, leading to two issues:
> 1. Only the code paths for shared skbs can be tested.
> 2. Skbs can only be released by pktgen.
> To enhance testing comprehensiveness, introducing the "skb_single_user"
> parameter, which allows skbs with a reference count of 1 to be
> transmitted. So we can test non-shared skbs and code paths where skbs
> are released within the network stack.
If my understanding of the code is correct, pktgen operates in the same
way with parameter clone_skb = 0 and clone_skb = 1.
clone_skb = 0 is already meant to work on devices that don't support
shared skbs (see IFF_TX_SKB_SHARING check in pktgen_if_write()). Instead
of introducing a new option for your purpose, how about changing
pktgen_xmit() to send "not shared" skbs when clone_skb == 0?
Note that for devices without IFF_TX_SKB_SHARING, it would no longer be
possible to have pktgen free skbs. Is that important?
next prev parent reply other threads:[~2023-09-06 22:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 10:35 [RFC PATCH net-next] pktgen: Introducing a parameter for non-shared skb testing Liang Chen
2023-09-06 22:32 ` Benjamin Poirier [this message]
2023-09-07 3:54 ` Liang Chen
2023-09-07 20:19 ` Benjamin Poirier
2023-09-11 6:25 ` Liang Chen
2023-09-13 4:51 ` Liang Chen
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=ZPj98UXjJdsEsVJQ@d3 \
--to=benjamin.poirier@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=liangchen.linux@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.