[dpdk-dev] [PATCH V19 4/4] app/testpmd: use auto handle for hotplug

[Matan Azrad]

Hi Guo

From: Guo, Jia, Friday, April 13, 2018 1:48 PM
> hi matan
> 
> 
> On 4/12/2018 1:31 PM, Matan Azrad wrote:
> > Hi All
> >
> > From: Jeff Guo, Friday, April 6, 2018 1:57 PM
> >> Use testpmd for example, to show how an application smoothly handle
> >> failure when device be hot removal, and show how to auto bind kernal
> >> driver to preparing attach device when device being hot insertion.
> > I saw the kmod of old devices were saved by name and the app hope that
> new device name will be as previous saved name.
> > How can the application know which driver should be bind for any new
> device?
> about which driver should be bind, that is assume that the app record the
> previous saved driver type,  if the device name match the name list ,just auto
> bind the corresponding saved driver, that is aim to application could bind
> driver at run time,

Looks like you assume that the device is always plugged in while the DPDK application starts, this is not true.

Hot-plug means the device may be plugged-out all the time even in the DPDK initialization.

In this case the plug-in process cannot be completely done by this implementation.

> > Moreover, I think that the application should not deal with driver
> > binding\remap and all this should be managed by the relevant PMDs -
> Looks like the bind mechanism should be managed directly by the PMDs and
> not annoying application to deal with it.
> >
> > Am I missing something?
>   partial agree, binding/remap could be managed by PMD, or more by hotplug
> framework. but i don't found the problem to exposure a api to binding
> according app's policy.

If the application asked the device to be probed (by whithlist\blaclist options in EAL command line)
The device should be probed and do the correct binding no need to request it from the user again,
because the PMD should have all the knowledge to do the bind in probe time.


> because, when device hot insertion, the PMDs default
> to bind a kernel driver, then before running testpmd , we bind specific driver
> by "dpdk-devbind.py" to override the driver, then run app.
> that override is  also the user behavior but not PMDs, so i think the different just at run time
> or setup time. i don't know if i convinced you here.

Maybe this is the time to deprecate that's need(bind device by script before dpdk running)  and to forward the binding responsibility to the PMDs.
So if the user asked the device it obviously should be bind to DPDK(\userland) so do the binding by DPDK PMDs.



> > Did you check the synchronization with the RMV event callback of ethdev?
> i guess you mean the RMV event from which PMDs have implement this
> hotplug event. right? 

Yes