DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Min Hu (Connor)" <humin29@huawei.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, <dev@dpdk.org>
Cc: <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [dpdk-dev] [PATCH] net/hns3: add runtime config to set MBX limit time
Date: Thu, 21 Oct 2021 10:26:01 +0800	[thread overview]
Message-ID: <300aa38f-ba08-d4e4-3246-a9847cde816f@huawei.com> (raw)
In-Reply-To: <22f0f080-b12b-2d7c-6d1b-4646252caec8@intel.com>

Hi, Ferruh,

在 2021/9/9 21:20, Ferruh Yigit 写道:
> On 8/30/2021 4:48 AM, Min Hu (Connor) wrote:
>> From: Chengchang Tang <tangchengchang@huawei.com>
>>
>> Current, the max waiting time for MBX response is 500ms, but in
>> some scenarios, it is not enough. Since it depends on the response
>> of the kernel mode driver, and its response time is related to the
>> scheduling of the system. In this special scenario, most of the
>> cores are isolated, and only a few cores are used for system
>> scheduling. When a large number of services are started, the
>> scheduling of the system will be very busy, and the reply of the
>> mbx message will time out, which will cause our PMD initialization
>> to fail.
>>
>> This patch add a runtime config to set the max wait time. For the
>> above scenes, users can adjust the waiting time to a suitable value
>> by themselves.
>>
>> Fixes: 463e748964f5 ("net/hns3: support mailbox")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Chengchang Tang <tangchengchang@huawei.com>
>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>> ---
>>   drivers/net/hns3/hns3_ethdev.c    | 26 +++++++++++++++++++++++++-
>>   drivers/net/hns3/hns3_ethdev.h    |  3 +++
>>   drivers/net/hns3/hns3_ethdev_vf.c |  3 ++-
>>   drivers/net/hns3/hns3_mbx.c       | 10 +++++++---
>>   drivers/net/hns3/hns3_mbx.h       |  1 +
>>   5 files changed, 38 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
>> index 7d37004..4c1a6f1 100644
>> --- a/drivers/net/hns3/hns3_ethdev.c
>> +++ b/drivers/net/hns3/hns3_ethdev.c
>> @@ -7357,9 +7357,24 @@ hns3_parse_dev_caps_mask(const char *key, const char *value, void *extra_args)
>>   	return 0;
>>   }
>>   
>> +static int
>> +hns3_parse_mbx_time_limit(const char *key, const char *value, void *extra_args)
>> +{
>> +	uint32_t val;
>> +
>> +	RTE_SET_USED(key);
>> +
>> +	val = strtoul(value, NULL, 10);
>> +	if (val > HNS3_MBX_DEF_TIME_LIMIT_MS && val <= UINT16_MAX)
> 
> This check adds a restriction that timeout can't be set less the 500ms but this
> restriction is not documented in the help string, comment or commit log etc...
> Can you either remove the restriction or document it?
Fixed in v2, please check it out.
> 
>> +		*(uint16_t *)extra_args = val;
>> +
>> +	return 0;
>> +}
>> +
>>   void
>>   hns3_parse_devargs(struct rte_eth_dev *dev)
>>   {
>> +	uint16_t mbx_time_limit_ms = HNS3_MBX_DEF_TIME_LIMIT_MS;
>>   	struct hns3_adapter *hns = dev->data->dev_private;
>>   	uint32_t rx_func_hint = HNS3_IO_FUNC_HINT_NONE;
>>   	uint32_t tx_func_hint = HNS3_IO_FUNC_HINT_NONE;
>> @@ -7380,6 +7395,9 @@ hns3_parse_devargs(struct rte_eth_dev *dev)
>>   			   &hns3_parse_io_hint_func, &tx_func_hint);
>>   	(void)rte_kvargs_process(kvlist, HNS3_DEVARG_DEV_CAPS_MASK,
>>   			   &hns3_parse_dev_caps_mask, &dev_caps_mask);
>> +	(void)rte_kvargs_process(kvlist, HNS3_DEVARG_MBX_TIME_LIMIT_MS,
>> +			   &hns3_parse_mbx_time_limit, &mbx_time_limit_ms);
>> +
>>   	rte_kvargs_free(kvlist);
>>   
>>   	if (rx_func_hint != HNS3_IO_FUNC_HINT_NONE)
>> @@ -7395,6 +7413,11 @@ hns3_parse_devargs(struct rte_eth_dev *dev)
>>   		hns3_warn(hw, "parsed %s = 0x%" PRIx64 ".",
>>   			  HNS3_DEVARG_DEV_CAPS_MASK, dev_caps_mask);
>>   	hns->dev_caps_mask = dev_caps_mask;
>> +
>> +	if (mbx_time_limit_ms != HNS3_MBX_DEF_TIME_LIMIT_MS)
>> +		hns3_warn(hw, "parsed %s = %u.", HNS3_DEVARG_MBX_TIME_LIMIT_MS,
>> +				mbx_time_limit_ms);
>> +	hns->mbx_time_limit_ms = mbx_time_limit_ms;
>>   }
>>   
>>   static const struct eth_dev_ops hns3_eth_dev_ops = {
>> @@ -7651,6 +7674,7 @@ RTE_PMD_REGISTER_KMOD_DEP(net_hns3, "* igb_uio | vfio-pci");
>>   RTE_PMD_REGISTER_PARAM_STRING(net_hns3,
>>   		HNS3_DEVARG_RX_FUNC_HINT "=vec|sve|simple|common "
>>   		HNS3_DEVARG_TX_FUNC_HINT "=vec|sve|simple|common "
>> -		HNS3_DEVARG_DEV_CAPS_MASK "=<1-65535> ");
>> +		HNS3_DEVARG_DEV_CAPS_MASK "=<1-65535> "
>> +		HNS3_DEVARG_MBX_TIME_LIMIT_MS "=<uint16> ");
>>   RTE_LOG_REGISTER_SUFFIX(hns3_logtype_init, init, NOTICE);
>>   RTE_LOG_REGISTER_SUFFIX(hns3_logtype_driver, driver, NOTICE);
>> diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
>> index 0e4e426..6476ad5 100644
>> --- a/drivers/net/hns3/hns3_ethdev.h
>> +++ b/drivers/net/hns3/hns3_ethdev.h
>> @@ -852,6 +852,7 @@ struct hns3_adapter {
>>   	uint32_t tx_func_hint;
>>   
>>   	uint64_t dev_caps_mask;
>> +	uint16_t mbx_time_limit_ms; /* wait time for mbx message */
>>   
>>   	struct hns3_ptype_table ptype_tbl __rte_cache_aligned;
>>   };
>> @@ -869,6 +870,8 @@ enum {
>>   
>>   #define HNS3_DEVARG_DEV_CAPS_MASK	"dev_caps_mask"
>>   
>> +#define HNS3_DEVARG_MBX_TIME_LIMIT_MS	"mbx_time_limit_ms"
>> +
>>   enum {
>>   	HNS3_DEV_SUPPORT_DCB_B,
>>   	HNS3_DEV_SUPPORT_COPPER_B,
>> diff --git a/drivers/net/hns3/hns3_ethdev_vf.c b/drivers/net/hns3/hns3_ethdev_vf.c
>> index 8d9b797..7ed9cb2 100644
>> --- a/drivers/net/hns3/hns3_ethdev_vf.c
>> +++ b/drivers/net/hns3/hns3_ethdev_vf.c
>> @@ -3115,4 +3115,5 @@ RTE_PMD_REGISTER_KMOD_DEP(net_hns3_vf, "* igb_uio | vfio-pci");
>>   RTE_PMD_REGISTER_PARAM_STRING(net_hns3_vf,
>>   		HNS3_DEVARG_RX_FUNC_HINT "=vec|sve|simple|common "
>>   		HNS3_DEVARG_TX_FUNC_HINT "=vec|sve|simple|common "
>> -		HNS3_DEVARG_DEV_CAPS_MASK "=<1-65535> ");
>> +		HNS3_DEVARG_DEV_CAPS_MASK "=<1-65535> "
>> +		HNS3_DEVARG_MBX_TIME_LIMIT_MS "=<uint16_t> ");
>> diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
>> index f36cb10..a1556f7 100644
>> --- a/drivers/net/hns3/hns3_mbx.c
>> +++ b/drivers/net/hns3/hns3_mbx.c
>> @@ -61,8 +61,9 @@ static int
>>   hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
>>   		  uint8_t *resp_data, uint16_t resp_len)
>>   {
>> -#define HNS3_MAX_RETRY_US	500000
>>   #define HNS3_WAIT_RESP_US	100
>> +#define US_PER_MS		1000
>> +	uint32_t mbx_time_limit = HNS3_MBX_DEF_TIME_LIMIT_MS * US_PER_MS;
>>   	struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
>>   	struct hns3_mbx_resp_status *mbx_resp;
>>   	uint32_t wait_time = 0;
>> @@ -74,7 +75,10 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
>>   		return -EINVAL;
>>   	}
>>   
>> -	while (wait_time < HNS3_MAX_RETRY_US) {
>> +	if (hns->mbx_time_limit_ms > HNS3_MBX_DEF_TIME_LIMIT_MS)
>> +		mbx_time_limit = (uint32_t)hns->mbx_time_limit_ms * US_PER_MS;
>> +
> 
> Why calculating the 'mbx_time_limit' twice in this function, isn't
> 'hns->mbx_time_limit_ms' has already either default value or user provided
> value, why not just keep this calculation even with removing above check?
> 
Fixed in v2, please check it out.
>> +	while (wait_time < mbx_time_limit) {
>>   		if (__atomic_load_n(&hw->reset.disable_cmd, __ATOMIC_RELAXED)) {
>>   			hns3_err(hw, "Don't wait for mbx respone because of "
>>   				 "disable_cmd");
>> @@ -103,7 +107,7 @@ hns3_get_mbx_resp(struct hns3_hw *hw, uint16_t code, uint16_t subcode,
>>   		wait_time += HNS3_WAIT_RESP_US;
>>   	}
>>   	hw->mbx_resp.req_msg_data = 0;
>> -	if (wait_time >= HNS3_MAX_RETRY_US) {
>> +	if (wait_time >= mbx_time_limit) {
>>   		hns3_mbx_proc_timeout(hw, code, subcode);
>>   		return -ETIME;
>>   	}
>> diff --git a/drivers/net/hns3/hns3_mbx.h b/drivers/net/hns3/hns3_mbx.h
>> index f868e33..d637bd2 100644
>> --- a/drivers/net/hns3/hns3_mbx.h
>> +++ b/drivers/net/hns3/hns3_mbx.h
>> @@ -87,6 +87,7 @@ enum hns3_mbx_link_fail_subcode {
>>   
>>   #define HNS3_MBX_MAX_MSG_SIZE	16
>>   #define HNS3_MBX_MAX_RESP_DATA_SIZE	8
>> +#define HNS3_MBX_DEF_TIME_LIMIT_MS	500
>>   
>>   enum {
>>   	HNS3_MBX_RESP_MATCHING_SCHEME_OF_ORIGINAL = 0,
>>
> 
> .
> 

  reply	other threads:[~2021-10-21  2:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-30  3:48 Min Hu (Connor)
2021-09-09 13:20 ` Ferruh Yigit
2021-10-21  2:26   ` Min Hu (Connor) [this message]
2021-10-21  2:22 ` [dpdk-dev] [PATCH v2] " Min Hu (Connor)
2021-10-21 13:06   ` Ferruh Yigit
2021-10-22  1:41     ` Min Hu (Connor)
2021-10-22  1:38 ` [dpdk-dev] [PATCH v3] " Min Hu (Connor)
2021-10-22  2:13   ` 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=300aa38f-ba08-d4e4-3246-a9847cde816f@huawei.com \
    --to=humin29@huawei.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@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).