From: Olivier MATZ <olivier.matz@6wind.com>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 3/4] ixgbe: automatic link recovery on VF
Date: Tue, 17 May 2016 09:50:49 +0200 [thread overview]
Message-ID: <573ACD59.3010806@6wind.com> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC090903468932@shsmsx102.ccr.corp.intel.com>
Hi Wenzhuo,
On 05/17/2016 03:11 AM, Lu, Wenzhuo wrote:
>> -----Original Message-----
>> From: Olivier Matz [mailto:olivier.matz@6wind.com]
>> If I understand well, ixgbevf_dev_link_up_down_handler() is called by
>> ixgbevf_recv_pkts_fake() on a dataplane core. It means that the core that
>> acquired the lock will loop during 100us + 1sec at least.
>> If this core was also in charge of polling other queues of other ports, or timers,
>> many packets will be dropped (even with a 100us loop). I don't think it is
>> acceptable to actively wait inside a rx function.
>>
>> I think it would avoid many issues to delegate this work to the application,
>> maybe by notifying it that the port is in a bad state and must be restarted. The
>> application could then properly stop polling the queues, and stop and restart the
>> port in a separate thread, without bothering the dataplane cores.
> Thanks for the comments.
> Yes, you're right. I had a wrong assumption that every queue is handled by one core.
> But surely it's not right, we cannot tell how the users will deploy their system.
>
> I plan to update this patch set. The solution now is, first let the users choose if they want this
> auto-reset feature. If so, we will apply another series rx/tx functions which have lock. So we
> can stop the rx/tx of the bad ports.
> And we also apply a reset API for users. The APPs should call this API in their management thread or so.
> It means APPs should guarantee the thread safe for the API.
> You see, there're 2 things,
> 1, Lock the rx/tx to stop them for users.
> 2, Apply a resetting API for users, and every NIC can do their own job. APPs need not to worry about the difference
> between different NICs.
>
> Surely, it's not *automatic* now. The reason is DPDK doesn't guarantee the thread safe. So the operations have to be
> left to the APPs and let them to guarantee the thread safe.
>
> And if the users choose not using auto-reset feature, we will leave this work to the APP :)
Yes, I think having 2 modes is a good approach:
- the first mode would let the application know a reset has to
be performed, without active loop or lock in the rx/tx funcs.
- the second mode would transparently manage the reset in the driver,
but may lock the core during some time.
By the way, you talk about a reset API, why not just using the
usual stop/start functions? I think it would work the same.
Regards,
Olivier
next prev parent reply other threads:[~2016-05-17 7:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 21:10 [dpdk-dev] [PATCH 0/4] automatic link recovery on ixgbe/igb VF Wenzhuo Lu
2016-05-04 21:10 ` [dpdk-dev] [PATCH 1/4] ixgbe: VF supports mailbox interruption for PF link up/down Wenzhuo Lu
2016-05-04 21:10 ` [dpdk-dev] [PATCH 2/4] igb: " Wenzhuo Lu
2016-05-04 21:10 ` [dpdk-dev] [PATCH 3/4] ixgbe: automatic link recovery on VF Wenzhuo Lu
2016-05-16 12:01 ` Olivier Matz
2016-05-17 1:11 ` Lu, Wenzhuo
2016-05-17 7:50 ` Olivier MATZ [this message]
2016-05-17 8:20 ` Lu, Wenzhuo
2016-05-04 21:10 ` [dpdk-dev] [PATCH 4/4] igb: " Wenzhuo Lu
2016-05-24 5:46 ` [dpdk-dev] [PATCH 0/4] automatic link recovery on ixgbe/igb VF Lu, Wenzhuo
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=573ACD59.3010806@6wind.com \
--to=olivier.matz@6wind.com \
--cc=dev@dpdk.org \
--cc=wenzhuo.lu@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).