From: Stephen Hemminger <stephen@networkplumber.org>
To: Qi Zhang <qi.z.zhang@intel.com>
Cc: thomas@monjalon.net, konstantin.ananyev@intel.com,
declan.doherty@intel.com, ferruh.yigit@intel.com, dev@dpdk.org,
benjamin.h.shelton@intel.com, narender.vangati@intel.com,
beilei.xing@intel.com, wenzhuo.lu@intel.com,
0000-cover-letter.patch@dpdk.org
Subject: Re: [dpdk-dev] [RFC 1/4] ethdev: claim device reset as async
Date: Wed, 8 Aug 2018 08:13:25 -0700 [thread overview]
Message-ID: <20180808081325.00df3024@xeon-e3> (raw)
In-Reply-To: <20180808070045.13334-1-qi.z.zhang@intel.com>
On Wed, 8 Aug 2018 15:00:42 +0800
Qi Zhang <qi.z.zhang@intel.com> wrote:
> rte_eth_dev_reset should be implemented in an async way since it is
> possible be invoked in interrupt thread and sometimes to reset a
> device need to wait for some dependency, for example, a VF expects
> for PF ready, or a NIC function as part of a SOC wait for the whole
> system reset complete, all these time consuming task will block the
> the interrupt thread.
> The patch claims rte_eth_dev_reset is an async function and introduce
> a new event RTE_ETH_EVENT_RESET_COMPLETE. PMD should raise this event
> when finish reset in background. The applicaiton should always wait
> for this event before continue to configure and restart the device.
If you have to change every driver to spawn a thread, then this doesn't
seem that useful. If you have to have a thread, then the base layer
code in EAL should do it.
Lots of DPDK changes seem to require every driver to change (a nuisance),
and then every driver changes in the same boilerplate way (indicates
poor design choice).
next prev parent reply other threads:[~2018-08-08 15:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-08 7:00 Qi Zhang
2018-08-08 7:00 ` [dpdk-dev] [RFC 2/4] net/i40e: enable async device reset Qi Zhang
2018-08-08 7:00 ` [dpdk-dev] [RFC 3/4] net/ixgbe: " Qi Zhang
2018-08-08 7:00 ` [dpdk-dev] [RFC 4/4] testpmd: " Qi Zhang
2018-08-08 11:15 ` [dpdk-dev] [RFC 1/4] ethdev: claim device reset as async Kevin Traynor
2018-08-15 1:30 ` Zhang, Qi Z
2018-08-08 15:13 ` Stephen Hemminger [this message]
2018-08-08 15:22 ` Andrew Rybchenko
2018-08-09 0:41 ` Zhang, Qi Z
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=20180808081325.00df3024@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=0000-cover-letter.patch@dpdk.org \
--cc=beilei.xing@intel.com \
--cc=benjamin.h.shelton@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=narender.vangati@intel.com \
--cc=qi.z.zhang@intel.com \
--cc=thomas@monjalon.net \
--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).