From: oulijun <oulijun@huawei.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: <xiaoyun.li@intel.com>, <dev@dpdk.org>, <linuxarm@openeuler.org>,
"Andrew Rybchenko" <arybchenko@solarflare.com>,
Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH V2] app/testpmd: support Tx mbuf free on demand cmd
Date: Tue, 9 Mar 2021 16:49:22 +0800 [thread overview]
Message-ID: <e86afc1f-550c-7c74-f689-763bcd001864@huawei.com> (raw)
In-Reply-To: <cddc69fa-c260-e08a-3b39-63538e3e9399@intel.com>
在 2021/3/9 1:33, Ferruh Yigit 写道:
> On 3/5/2021 9:57 AM, Lijun Ou wrote:
>> From: Chengwen Feng <fengchengwen@huawei.com>
>>
>> This patch support tx_done_cleanup command:
>> tx_done_cleanup port (port_id) (queue_id) (free_cnt)
>>
>> Users must make sure there are no concurrent access to the same Tx
>> queue (like rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on)
>> this command executed.
>>
>
> Hi Lijun,
>
> Is the intention to test the PMD implementation?
Yes
> As you highlighted the API is for the datapath, a command for it is not
> easy to use, not sure how useful it will be.
> Perhaps it can be option to use this API in a forwarding engine, like
> 'txonly', controlled by a command, but again not sure what to
> observe/measure etc..
>
We want to do this. But it is diffcult to control the number of sent
packets when used together with other txonly.
>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>> Signed-off-by: Lijun Ou <oulijun@huawei.com>
>> ---
>> V1->V2:
>> - use Tx instead of TX
>> - add note in doc
>> ---
>> app/test-pmd/cmdline.c | 91
>> +++++++++++++++++++++++++++++
>> doc/guides/rel_notes/release_21_05.rst | 2 +
>> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 ++++
>> 3 files changed, 104 insertions(+)
>>
>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>> index 14110eb..4df0c32 100644
>> --- a/app/test-pmd/cmdline.c
>> +++ b/app/test-pmd/cmdline.c
>> @@ -36,6 +36,7 @@
>> #include <rte_pci.h>
>> #include <rte_ether.h>
>> #include <rte_ethdev.h>
>> +#include <rte_ethdev_driver.h>
>
> This header for PMDs to include, applications shouldn't include this,
> including this means you are accessing dpdk internals which you
> shouldn't access.
>
Thanks. I will fix it.
>> #include <rte_string_fns.h>
>> #include <rte_devargs.h>
>> #include <rte_flow.h>
>> @@ -675,6 +676,9 @@ static void cmd_help_long_parsed(void *parsed_result,
>> "set port (port_id) ptype_mask (ptype_mask)\n"
>> " set packet types classification for a specific
>> port\n\n"
>> + "tx_done_cleanup (port_id) (queue_id) (free_cnt)\n"
>> + " Cleanup a Tx queue's mbuf on a port\n\n"
>> +
>> "set port (port_id) queue-region region_id (value) "
>> "queue_start_index (value) queue_num (value)\n"
>> " Set a queue region on a port\n\n"
>> @@ -16910,6 +16914,92 @@ cmdline_parse_inst_t cmd_showport_macs = {
>> },
>> };
>> +/* *** tx_done_cleanup *** */
>> +struct cmd_tx_done_cleanup_result {
>> + cmdline_fixed_string_t clean;
>> + cmdline_fixed_string_t port;
>> + uint16_t port_id;
>> + uint16_t queue_id;
>> + uint32_t free_cnt;
>> +};
>> +
>> +static void
>> +cmd_tx_done_cleanup_parsed(void *parsed_result,
>> + __rte_unused struct cmdline *cl,
>> + __rte_unused void *data)
>> +{
>> + struct cmd_tx_done_cleanup_result *res = parsed_result;
>> + struct rte_eth_dev *dev;
>> + uint16_t port_id = res->port_id;
>> + uint16_t queue_id = res->queue_id;
>> + uint32_t free_cnt = res->free_cnt;
>> + int ret;
>> +
>> + if (!rte_eth_dev_is_valid_port(port_id)) {
>> + printf("Invalid port_id %u\n", port_id);
>> + return;
>> + }
>> +
>> + dev = &rte_eth_devices[port_id];
>
> Similar to above comment 'rte_eth_devices' is the internal variable,
> applications should not access it directly.
>
No API is available, and multiple references exist in the testpmd file.
>> + if (queue_id >= dev->data->nb_tx_queues) {
>> + printf("Invalid Tx queue_id %u\n", queue_id);
>> + return;
>> + }
>> +
>
> Number of the queues can be get via 'rte_eth_dev_info_get()'.
>
This is also called in txonly. Do you want to replace it?
>> + if (dev->data->tx_queue_state[queue_id] !=
>> + RTE_ETH_QUEUE_STATE_STARTED) {
>> + printf("Tx queue_id %u not started!\n", queue_id);
>> + return;
>> + }
>> +
>
> I am not sure if we have an API to get this information, if there is a
> need from application to get this data we should consider adding a new
> API. cc'ed Andrew and Thomas.
>
>> + /*
>> + * rte_eth_tx_done_cleanup is a dataplane API, user must make sure
>> + * there are no concurrent access to the same Tx queue (like
>> + * rte_eth_tx_burst, rte_eth_dev_tx_queue_stop and so on) when
>> this API
>> + * called.
>> + */
>> + ret = rte_eth_tx_done_cleanup(port_id, queue_id, free_cnt);
>> + if (ret < 0) {
>> + printf("Failed to cleanup mbuf for port %u Tx queue %u "
>> + "error desc: %s(%d)\n",
>> + port_id, queue_id, strerror(-ret), ret);
>> + return;
>> + }
>> +
>> + printf("Cleanup port %u Tx queue %u mbuf nums: %u\n",
>> + port_id, queue_id, ret);
>> +}
>> +
>> +cmdline_parse_token_string_t cmd_tx_done_cleanup_clean =
>> + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, clean,
>> + "tx_done_cleanup");
>> +cmdline_parse_token_string_t cmd_tx_done_cleanup_port =
>> + TOKEN_STRING_INITIALIZER(struct cmd_tx_done_cleanup_result, port,
>> + "port");
>> +cmdline_parse_token_num_t cmd_tx_done_cleanup_port_id =
>> + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, port_id,
>> + UINT16);
>> +cmdline_parse_token_num_t cmd_tx_done_cleanup_queue_id =
>> + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, queue_id,
>> + UINT16);
>> +cmdline_parse_token_num_t cmd_tx_done_cleanup_free_cnt =
>> + TOKEN_NUM_INITIALIZER(struct cmd_tx_done_cleanup_result, free_cnt,
>> + UINT32);
>> +
>> +cmdline_parse_inst_t cmd_tx_done_cleanup = {
>> + .f = cmd_tx_done_cleanup_parsed,
>> + .data = NULL,
>> + .help_str = "tx_done_cleanup port <port_id> <queue_id> <free_cnt>",
>> + .tokens = {
>> + (void *)&cmd_tx_done_cleanup_clean,
>> + (void *)&cmd_tx_done_cleanup_port,
>> + (void *)&cmd_tx_done_cleanup_port_id,
>> + (void *)&cmd_tx_done_cleanup_queue_id,
>> + (void *)&cmd_tx_done_cleanup_free_cnt,
>> + NULL,
>> + },
>> +};
>> +
>> /*
>> ********************************************************************************
>> */
>> /* list of instructions */
>> @@ -17035,6 +17125,7 @@ cmdline_parse_ctx_t main_ctx[] = {
>> (cmdline_parse_inst_t *)&cmd_config_rss_reta,
>> (cmdline_parse_inst_t *)&cmd_showport_reta,
>> (cmdline_parse_inst_t *)&cmd_showport_macs,
>> + (cmdline_parse_inst_t *)&cmd_tx_done_cleanup,
>> (cmdline_parse_inst_t *)&cmd_config_burst,
>> (cmdline_parse_inst_t *)&cmd_config_thresh,
>> (cmdline_parse_inst_t *)&cmd_config_threshold,
>> diff --git a/doc/guides/rel_notes/release_21_05.rst
>> b/doc/guides/rel_notes/release_21_05.rst
>> index 23f7f0b..8077573 100644
>> --- a/doc/guides/rel_notes/release_21_05.rst
>> +++ b/doc/guides/rel_notes/release_21_05.rst
>> @@ -69,6 +69,8 @@ New Features
>> * Added command to display Rx queue used descriptor count.
>> ``show port (port_id) rxq (queue_id) desc used count``
>> + * Added command to cleanup a Tx queue's mbuf on a port.
>> + ``tx_done_cleanup port <port_id> <queue_id> <free_cnt>``
>> Removed Items
>> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>> index f59eb8a..fa49e58 100644
>> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
>> @@ -272,6 +272,17 @@ and ready to be processed by the driver on a
>> given RX queue::
>> testpmd> show port (port_id) rxq (queue_id) desc used count
>> +cleanup txq mbufs
>> +~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +Request the driver to free mbufs currently cached by the driver for a
>> given port's
>> +Tx queue::
>> + testpmd> tx_done_cleanup port (port_id) (queue_id) (free_cnt)
>> +
>> +.. note::
>> + This command is dangerous, users must make sure there are no
>> cucurrent access to
>> + the same Tx queue (link rte_eth_tx_burst,
>> rte_eth_dev_tx_queue_stop and so on).
>> +
>> show config
>> ~~~~~~~~~~~
>>
>
> .
>
next prev parent reply other threads:[~2021-03-09 8:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 7:33 [dpdk-dev] [PATCH] " Lijun Ou
2021-03-05 7:46 ` Li, Xiaoyun
2021-03-05 9:58 ` oulijun
2021-03-05 9:57 ` [dpdk-dev] [PATCH V2] " Lijun Ou
2021-03-08 17:33 ` Ferruh Yigit
2021-03-09 8:49 ` oulijun [this message]
2021-03-09 9:53 ` Ferruh Yigit
2021-03-09 9:57 ` Thomas Monjalon
2021-03-09 10:18 ` Andrew Rybchenko
2021-03-09 14:00 ` Aaron Conole
2021-03-09 14:13 ` Ferruh Yigit
2021-03-10 1:48 ` oulijun
2021-03-10 7:59 ` Thomas Monjalon
2021-03-12 10:29 ` [dpdk-dev] [Linuxarm] " oulijun
2021-03-12 11:21 ` Thomas Monjalon
2021-03-17 11:30 ` oulijun
2021-03-17 12:07 ` Thomas Monjalon
2021-03-18 3:56 ` oulijun
2021-03-18 7:51 ` Thomas Monjalon
2021-04-12 13:12 ` [dpdk-dev] [PATCH V3] " Lijun Ou
2021-04-19 3:11 ` Li, Xiaoyun
2021-04-19 12:40 ` oulijun
2021-04-19 14:56 ` Ferruh Yigit
2021-04-19 12:36 ` [dpdk-dev] [PATCH V4] " Lijun Ou
2021-04-19 15:28 ` Ferruh Yigit
2021-04-21 1:44 ` oulijun
2021-04-21 8:09 ` [dpdk-dev] [PATCH V5] app/test-pmd: support cleanup txq mbufs command Lijun Ou
2021-04-21 8:15 ` Ferruh Yigit
2021-04-21 8:32 ` oulijun
2021-04-21 8:45 ` [dpdk-dev] [PATCH V6] " Lijun Ou
2021-04-21 11:26 ` Ferruh Yigit
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=e86afc1f-550c-7c74-f689-763bcd001864@huawei.com \
--to=oulijun@huawei.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=linuxarm@openeuler.org \
--cc=thomas@monjalon.net \
--cc=xiaoyun.li@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).