DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Dengdui Huang <huangdengdui@huawei.com>,
	dev@dpdk.org
Cc: stephen@networkplumber.org, thomas@monjalon.net,
	aman.deep.singh@intel.com, yuying.zhang@intel.com,
	anatoly.burakov@intel.com, lihuisong@huawei.com,
	liuyonglong@huawei.com, liudongdong3@huawei.com
Subject: Re: [PATCH v2 1/2] ethdev: add API to check queue ID validity
Date: Wed, 31 May 2023 17:31:10 +0100	[thread overview]
Message-ID: <b9d74c48-b2c5-0d2e-3f63-54b74d8340fe@amd.com> (raw)
In-Reply-To: <e8386625-7b4b-901b-720e-88b7671e6a3f@oktetlabs.ru>

On 5/22/2023 2:58 PM, Andrew Rybchenko wrote:
> On 5/22/23 16:09, Dengdui Huang wrote:
>> The API rte_eth_dev_is_valid_rxq/txq checks
>> the port ID validity and then the Rx/Tx queue ID is valid.
> 
> What is valid Tx/Rx queue? It depends on on caller
> expectations. Some functions are satisfied with just
> check vs configured number of queues. Some require
> the queue to be setup. May be some should require
> the queue to be started.
> 
> So, I suggest to avoid term "valid" and be more precise
> here and API naming.
> 

I understand the concern 'valid' keyword, but we already have an API as
'rte_eth_dev_is_valid_port()', which does similar checks,

so 'rte_eth_dev_is_valid_rxq()' & 'rte_eth_dev_is_valid_txq()' looks
consistent with it.

v3 has API names, 'rte_eth_dev_rxq_avail()' & 'rte_eth_dev_txq_avail()',
I am not sure about these naming too, it feels like queues are valid but
it maybe in available and not available states.


@Andrew, do you have any suggestion on the API naming?
If not I am for going with rte_eth_dev_is_valid_rxq()' &
'rte_eth_dev_is_valid_txq()' mainly because of existing
'rte_eth_dev_is_valid_port()' API.

Perhaps we can elaborate what 'valid' means in API documentation to help
users.

>>
>> Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
>> ---
>>   doc/guides/rel_notes/release_23_07.rst |  5 ++++
>>   lib/ethdev/rte_ethdev.c                | 30 +++++++++++++++++++++
>>   lib/ethdev/rte_ethdev.h                | 36 ++++++++++++++++++++++++++
>>   lib/ethdev/version.map                 |  4 +++
>>   4 files changed, 75 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/release_23_07.rst
>> b/doc/guides/rel_notes/release_23_07.rst
>> index a9b1293689..19e645156f 100644
>> --- a/doc/guides/rel_notes/release_23_07.rst
>> +++ b/doc/guides/rel_notes/release_23_07.rst
>> @@ -56,6 +56,11 @@ New Features
>>        =======================================================
>>     +* **Added ethdev Rx/Tx queue id check API.**
>> +
>> +  Added ethdev Rx/Tx queue id check API which provides functions
> 
> id -> ID
> 
>> +  for check if Rx/Tx queue id is valid.
> 
> id -> ID
> 
>> +
> 
> It should be two empty lines here and just one above.
> 
>>   Removed Items
>>   -------------
>>   diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index 4d03255683..3d85218127 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -407,6 +407,36 @@ rte_eth_dev_is_valid_port(uint16_t port_id)
>>       return is_valid;
>>   }
>>   +int
>> +rte_eth_dev_is_valid_rxq(uint16_t port_id, uint16_t queue_id)
>> +{
>> +    struct rte_eth_dev *dev;
>> +
>> +    RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> +    dev = &rte_eth_devices[port_id];
>> +
>> +    if (queue_id >= dev->data->nb_rx_queues ||
>> +            dev->data->rx_queues[queue_id] == NULL)
> 
> We already have internal eth_dev_validate_tx_queue(). Shouldn't
> it be used here?
> 
> Also, some functions check that queues array is not NULL.
> If the the is excessive after queue number check, it
> should be consistent everywhere and corresponding check
> of the array pointer vs NULL should be removed in a separate
> cleanup patch. If the check is required in some corner cases
> (I hope no), it should be here as well.
> 
>> +        return -EINVAL;
>> +
>> +    return 0;
>> +}
> 
> [snip]
> 


  parent reply	other threads:[~2023-05-31 16:31 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16 11:00 [PATCH] app/testpmd: fix segment fault with invalid queue id Dengdui Huang
2023-05-16 15:12 ` Stephen Hemminger
2023-05-19 10:18   ` huangdengdui
2023-05-22 13:09 ` [PATCH v2 0/2] add API and use it to fix a bug Dengdui Huang
2023-05-22 13:09   ` [PATCH v2 1/2] ethdev: add API to check queue ID validity Dengdui Huang
2023-05-22 13:58     ` Andrew Rybchenko
2023-05-24  7:38       ` huangdengdui
2023-05-24  9:03         ` Andrew Rybchenko
2023-05-31 16:31       ` Ferruh Yigit [this message]
2023-06-01 22:13         ` Ferruh Yigit
2023-06-02  1:36           ` huangdengdui
2023-05-22 13:09   ` [PATCH v2 2/2] app/testpmd: fix segment fault with invalid queue id Dengdui Huang
2023-05-25  7:03 ` [PATCH v3 0/2] add Rx/Tx queue ID check API and use it to fix a bug Dengdui Huang
2023-05-25  7:03   ` [PATCH v3 1/2] ethdev: add API to check if queue is available Dengdui Huang
2023-05-25  7:03   ` [PATCH v3 2/2] app/testpmd: fix segment fault with invalid queue ID Dengdui Huang
2023-06-02  7:52 ` [PATCH v4 0/2] add Rx/Tx queue ID check API and use it to fix a bug Dengdui Huang
2023-06-02  7:52   ` [PATCH v4 1/2] ethdev: add API to check if queue is valid Dengdui Huang
2023-06-02 12:47     ` Ferruh Yigit
2023-06-05  1:24       ` huangdengdui
2023-06-02  7:52   ` [PATCH v4 2/2] app/testpmd: fix segment fault with invalid queue ID Dengdui Huang
2023-06-02 12:47     ` Ferruh Yigit
2023-06-05  2:27 ` [PATCH v5 0/2] add Rx/Tx queue ID check API and use it to fix a bug Dengdui Huang
2023-06-05  2:27   ` [PATCH v5 1/2] ethdev: add API to check if queue is valid Dengdui Huang
2023-06-06  9:06     ` Ferruh Yigit
2023-06-05  2:27   ` [PATCH v5 2/2] app/testpmd: fix segment fault with invalid queue ID Dengdui Huang
2023-06-06  9:07   ` [PATCH v5 0/2] add Rx/Tx queue ID check API and use it to fix a bug 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=b9d74c48-b2c5-0d2e-3f63-54b74d8340fe@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=aman.deep.singh@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=huangdengdui@huawei.com \
    --cc=lihuisong@huawei.com \
    --cc=liudongdong3@huawei.com \
    --cc=liuyonglong@huawei.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --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).