DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Eelco Chaudron" <echaudro@redhat.com>
To: "Xing, Beilei" <beilei.xing@intel.com>,
	"Zhang, Xiao" <xiao.zhang@intel.com>
Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state after VF reset
Date: Fri, 01 Nov 2019 09:12:51 +0100	[thread overview]
Message-ID: <724A0BBE-66F4-40D3-A38E-8F4E9C09ECC5@redhat.com> (raw)
In-Reply-To: <94479800C636CB44BD422CB454846E013CE7E99B@SHSMSX101.ccr.corp.intel.com>



On 1 Nov 2019, at 3:38, Xing, Beilei wrote:

>> -----Original Message-----
>> From: Eelco Chaudron [mailto:echaudro@redhat.com]
>> Sent: Tuesday, October 29, 2019 3:47 PM
>> To: Zhang, Xiao <xiao.zhang@intel.com>; Xing, Beilei 
>> <beilei.xing@intel.com>
>> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state 
>> after VF
>> reset
>>
>>
>>
>> On 29 Oct 2019, at 8:39, Zhang, Xiao wrote:
>>
>>>> -----Original Message-----
>>>> From: Eelco Chaudron <echaudro@redhat.com>
>>>> Sent: Friday, October 25, 2019 5:24 PM
>>>> To: Xing, Beilei <beilei.xing@intel.com>; Zhang, Xiao
>>>> <xiao.zhang@intel.com>
>>>> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org
>>>> Subject: Re: [dpdk-dev] [PATCH] net/i40e: force promiscuous state
>>>> after VF reset
>>>>
>>>>
>>>>
>>>> On 17 Oct 2019, at 8:34, Xing, Beilei wrote:
>>>>
>>>>>> On 17 Sep 2019, at 9:40, Eelco Chaudron wrote:
>>>>>>
>>>>>>> Even though the device reset is successful, disabling 
>>>>>>> promiscuous
>>>>>>> mode might not always succeed, causing enabling it after reset 
>>>>>>> to
>>>>>>> fail.
>>>>>>> This would happen when the kernel driver requires a reset of the
>>>>>>> VF.
>>>>>>>
>>>>>>> This patch resets the internal state, so next time promiscuous
>>>>>>> mode
>>>>>>> is configured it will be enabled.
>>>>>>>
>>>>>>> Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
>>>>>>> ---
>>>>>>>  drivers/net/i40e/i40e_ethdev_vf.c | 10 ++++++++++
>>>>>>>  1 file changed, 10 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
>>>>>>> b/drivers/net/i40e/i40e_ethdev_vf.c
>>>>>>> index 551f6fa..e0f99a4 100644
>>>>>>> --- a/drivers/net/i40e/i40e_ethdev_vf.c
>>>>>>> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
>>>>>>> @@ -2276,11 +2276,21 @@ static int eth_i40evf_pci_remove(struct
>>>>>>> rte_pci_device *pci_dev)  i40evf_dev_reset(struct rte_eth_dev
>>>>>>> *dev)
>>>>>>> {
>>>>>>>  	int ret;
>>>>>>> +	struct i40e_vf *vf =
>>>>>>> I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
>>>>>>>
>>>>>>>  	ret = i40evf_dev_uninit(dev);
>>>>>>>  	if (ret)
>>>>>>>  		return ret;
>>>>>>>
>>>>>>> +	/*
>>>>>>> +	 * Even though the device reset is successful disabling
>>>>>>> promiscuous
>>>>>>> +	 * mode might not always succeed, causing enabling it after
>>>>>>> reset
>>>>>>> to
>>>>>
>>>>> I think we need to root cause why fail to disable promiscuous mode
>>>>> and
>>>>> try to fix it first.
>>>>
>>>> I’ve copied in Xiao who helped me identify the issue in your
>>>> driver.
>>>>
>>>> The issue is because the change from kernel pf was not synced to 
>>>> DPDK
>>>> vf during
>>>> the closing period of reset, so we get this failure. Xiao can you 
>>>> add
>>>> more details?
>>>>
>>>
>>> The root cause is when kernel pf generate DPDK vf reset event, the
>>> flag
>>> vf->promisc_unicast_enabled will not be cleared but promiscuous mode
>>> is
>>> disabled. When trying to enable promiscuous mode next time by 
>>> calling
>>> i40evf_dev_promiscuous_enable won't work because it will check the
>>> vf->promisc_unicast_enabled flag first.
>>>
>>> static int
>>> i40evf_dev_promiscuous_enable(struct rte_eth_dev *dev)
>>> {
>>> ...
>>>     /* If enabled, just return */
>>>     if (vf->promisc_unicast_enabled)
>>>         return 0;
>>> ...
>>> }
>>>
>>> Hi Eelco,
>>>
>>> I think you may need add more detailed message in the commit log or
>>> comments.
>>
>> My interpretation of the request was that Beilei wanted to know why
>> disabling promiscuous mode in HW was failing. Beilei can you comment, 
>> is
>> the additional description from Xiao enough?
>
> Yes, promisc_unicast_enabled flag is not cleared during vf reset 
> because fail to disable promiscuous mode,
> So I think we need to root cause why fail to  disable promiscuous mode 
> first.
> This patch looks like a workaround but not a fix.
>

This was debugged together with Xiao and from what I understand is that 
DPDK fails to reset promiscuous mode in hardware as PF and VF operations 
are not synced between kernel and DPDK.

Xiao told me this could not be fixed in another way, Xiao can you 
comment?

>>
>>>>
>>>>>>> +	 * fail. This would happen when the kernel driver requires a
>>>>>>> reset
>>>>>>> +	 * of the VF.
>>>>>>> +	 */
>>>>>>> +	if (rte_eal_process_type() == RTE_PROC_PRIMARY)
>>>>>>> +		vf->promisc_unicast_enabled = FALSE;
>>>>>>> +
>>>>>>>  	ret = i40evf_dev_init(dev);
>>>>>>>
>>>>>>>  	return ret;
>>>>>>> --
>>>>>>> 1.8.3.1


  reply	other threads:[~2019-11-01  8:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17  7:40 Eelco Chaudron
2019-10-15 10:31 ` Eelco Chaudron
2019-10-17  6:34   ` Xing, Beilei
2019-10-25  9:23     ` Eelco Chaudron
2019-10-29  7:39       ` Zhang, Xiao
2019-10-29  7:47         ` Eelco Chaudron
2019-11-01  2:38           ` Xing, Beilei
2019-11-01  8:12             ` Eelco Chaudron [this message]
2019-11-06  4:58               ` Zhang, Xiao
2019-11-12  0:52                 ` Zhang, Xiao
2019-11-12 11:09                   ` Eelco Chaudron
2019-11-13  1:14                     ` Zhang, Xiao
2019-11-19 13:55                       ` Eelco Chaudron
2019-11-11 13:59               ` Eelco Chaudron

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=724A0BBE-66F4-40D3-A38E-8F4E9C09ECC5@redhat.com \
    --to=echaudro@redhat.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=qi.z.zhang@intel.com \
    --cc=xiao.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).