[dpdk-dev] [RFC 1/4] ethdev: claim device reset as async

Zhang, Qi Z qi.z.zhang at intel.com
Thu Aug 9 02:41:52 CEST 2018



> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, August 8, 2018 11:13 PM
> To: Zhang, Qi Z <qi.z.zhang at intel.com>
> Cc: thomas at monjalon.net; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>; Doherty, Declan
> <declan.doherty at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>;
> dev at dpdk.org; Shelton, Benjamin H <benjamin.h.shelton at intel.com>;
> Vangati, Narender <narender.vangati at intel.com>; Xing, Beilei
> <beilei.xing at intel.com>; Lu, Wenzhuo <wenzhuo.lu at intel.com>;
> 0000-cover-letter.patch at dpdk.org
> Subject: Re: [dpdk-dev] [RFC 1/4] ethdev: claim device reset as async
> 
> On Wed,  8 Aug 2018 15:00:42 +0800
> Qi Zhang <qi.z.zhang at 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.

It may not necessary for PMD which can do device reset quickly to spawn a thread, in that case, it just need to raise RTE_ETH_EVENT_RESET_COMPLETE
in the same thread. But I agree it is better to move thread spawn and event raise into ether layer as a standard way.

> 
> 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).


More information about the dev mailing list