-----Original Message----- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Monday, July 10, 2017 7:35 PM To: Dai, Wei <wei....@intel.com> Cc: tho...@monjalon.net; Lu, Wenzhuo <wenzhuo...@intel.com>; Ananyev, Konstantin <konstantin.anan...@intel.com>; Wu, Jingjing <jingjing...@intel.com>; Xing, Beilei <beilei.x...@intel.com>; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
-----Original Message----- > Date: Mon, 10 Jul 2017 18:05:41 +0800 > From: Wei Dai <wei....@intel.com> > To: tho...@monjalon.net, wenzhuo...@intel.com, > konstantin.anan...@intel.com, jingjing...@intel.com, > beilei.x...@intel.com > CC: dev@dpdk.org, Wei Dai <wei....@intel.com> > Subject: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > X-Mailer: git-send-email 2.7.5 > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > A DPDK application can call this function to reset a NIC and keep its > port id afterwards. > It means that all SW resources allocated in ethdev layer should be > kept and SW and HW resources of the NIC in PMD need to be reset in > similar way that it runs PCI dev_uninit() and then dev_init(). > The sequence of dev_uninit() and dev_init() can be packed into a > single interface API rte_eth_dev_reset(). > Please See the comments before the declaration of rte_eht_dev_reset() > in lib/librte_ether/rte_ethdev.h to get more details on why this > function is needed, what this function does and what an application > should do after calling this function. > > Signed-off-by: Wei Dai <wei....@intel.com> > --- > /** > + * Reset a Ethernet device and keep its port id. > + * > + * A DPDK application calls this function to do an initiative or > + passive > + * reset of a port. > + * > + * Sometimes a port have to be reset passively. For example a PF is > + reset, > + * all its VFs should also be reset by application itself to align > + with the > + * PF. May be I didn't understood this use case properly,But, PF can always send mailbox message to VF on PF reset. Right? [Wei: As to ixgbe, PF kernel driver always send mailbox message to VF when PF is reset. For other NICs, there are maybe other mechanism to notify VF of PF reset.] On such message from PF, VF can transparently reset without application knowledge(i.e rx and/or tx burst return zero) [Wei: VF reset is handling many HW registers which may have effect on working Rx/Tx path and may cause some unexpected behavior like crash. So application should make some operations like stopping Rx/Tx path before it begin VF reset. This is why application should handle VF reset itself.] > + * A DPDK application also can call this function to trigger an > + initative > + * port reset. When apart from the above use case? Even if it is above case, we should have some event to notify application to initiate the reset.Right? Without the event, When or on what basics application needs to initiate reset? [Wei: Indeed, until now we didn't see any use case which DPDK application initiative port reset itself. The most usual case is that PF is working with kernel driver and VFs are working with DPDK PMD. Some operations on kernel PF lead to a PF reset which causes its VF reset. Anyway this new function provides a possibility for application to trigger an initiative port reset.] > + *
