From: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
To: "Li, Xiaoyun" <xiaoyun.li@intel.com>,
"Zhang, Yuying" <yuying.zhang@intel.com>,
"Singh, Aman Deep" <aman.deep.singh@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: Raslan Darawsheh <rasland@nvidia.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Thomas Monjalon <tmonjalon@nvidia.com>,
Slava Ovsiienko <viacheslavo@nvidia.com>
Subject: RE: [PATCH] app/testpmd: skip stopped queues when forwarding
Date: Fri, 11 Feb 2022 10:42:49 +0000 [thread overview]
Message-ID: <BL1PR12MB594551A71273709E1C04A8BAB9309@BL1PR12MB5945.namprd12.prod.outlook.com> (raw)
In-Reply-To: <DM4PR11MB55340E120B1E614BAAE55A6C992E9@DM4PR11MB5534.namprd11.prod.outlook.com>
- jing.d.chen@intel.com (invalid address?), +ethdev maintainers
> From: Li, Xiaoyun <xiaoyun.li@intel.com>
> [...]
> Sorry to be direct, but I don't think this patch makes sense.
> I need the code to clarify the problems so I'll use this thread not
> the one you're answering.
Thank you for explaining the issues in great detail!
I'd like to understand one crucial point below
to decide whether testpmd needs any changes at all.
> [...]
> And I don't think it's that harmful to just let those fwd running even
> if you stop some rxq. Because their pair won't have pkts to do tx if
> there's no rx.
This patch was created with the assumption
that stopped queues may not be used for Rx/Tx.
No-op behavior of rte_eth_rx/tx_burst()
for a stopped queue is not documented.
Yes, at least some PMDs implement it this way.
But is this behavior intended?
It is the application that stops the queue or starts it deferred.
Stopping is non-atomic, so polling the queue is not allowed during it.
Hence, if the application intends to stop queues, it must either:
a) Know the queue is not polled before stopping it.
Use case: a secondary that was polling the queue has crashed,
the primary is doing a recovery to free all mbufs.
There is no issue since there is no poller to touch the queue.
b) Tell the poller to skip the queue for the time of stopping it.
Use case: deferred queue start or queue reconfiguration.
But if the poller is cooperating anyway,
what prevents it from not touching the queue for longer?
The same considerations apply to starting a queue.
No-op behavior is convenient from the application point of view.
But it also means that pollers of stopped queues
will go all the way down to PMD Rx/Tx routines, wasting cycles,
and some PMDs will do a check for the queue state,
even though it may never be needed for a particular application.
next prev parent reply other threads:[~2022-02-11 10:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 9:21 Dmitry Kozlyuk
2022-02-02 10:02 ` Dmitry Kozlyuk
2022-02-03 13:52 ` Singh, Aman Deep
2022-02-09 8:59 ` Zhang, Yuying
2022-02-09 10:38 ` Dmitry Kozlyuk
2022-02-09 14:56 ` Li, Xiaoyun
2022-02-11 10:42 ` Dmitry Kozlyuk [this message]
2022-02-21 8:58 ` Dmitry Kozlyuk
2022-02-24 9:28 ` Thomas Monjalon
2022-03-06 23:23 ` [PATCH v2 0/2] " Dmitry Kozlyuk
2022-03-06 23:23 ` [PATCH v2 1/2] ethdev: prohibit polling of a stopped queue Dmitry Kozlyuk
2022-03-06 23:23 ` [PATCH v2 2/2] app/testpmd: do not poll stopped queues Dmitry Kozlyuk
2022-03-07 12:53 ` [PATCH v3 0/2] app/testpmd: skip stopped queues when forwarding Dmitry Kozlyuk
2022-03-07 12:53 ` [PATCH v3 1/2] app/testpmd: do not poll stopped queues Dmitry Kozlyuk
2022-03-09 10:36 ` Dmitry Kozlyuk
2023-07-08 1:54 ` Stephen Hemminger
2022-05-25 15:46 ` Thomas Monjalon
2022-06-10 11:28 ` Jiang, YuX
2022-03-07 12:53 ` [PATCH v3 2/2] ethdev: prohibit polling of a stopped queue Dmitry Kozlyuk
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=BL1PR12MB594551A71273709E1C04A8BAB9309@BL1PR12MB5945.namprd12.prod.outlook.com \
--to=dkozlyuk@nvidia.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=rasland@nvidia.com \
--cc=tmonjalon@nvidia.com \
--cc=viacheslavo@nvidia.com \
--cc=xiaoyun.li@intel.com \
--cc=yuying.zhang@intel.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;
as well as URLs for NNTP newsgroup(s).