04/12/2017 09:08, Tan, Jianfeng: > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > > Hi, > > > > 01/12/2017 06:48, Tan, Jianfeng: > > > Hi Thomas, > > > > > > Please help us to understand why we need this. > > > > > > > > > On 12/1/2017 8:36 AM, Thomas Monjalon wrote: > > > > The scan callback allows to spawn a vdev automatically > > > > given some custom scan rules. > > > > > > These two new APIs (rte_vdev_add_custom_scan and > > > rte_vdev_remove_custom_scan) are called by applications? > > > > Yes, the application can use it but it can also be used by a DPDK > > driver or library. > > > > > If so, why not just constructing them in the parameters before passing > > > to rte_eal_init? > > > > It is not only for initialization because it will also work when > > we will have some hotplug mechanism where the scan is run during run-time. > > > > > > It is especially useful to create a TAP device automatically > > > > connected to a netdevice as remote. > > > > > > It sounds like an use case. Without this patch, I suppose we can already > > > do this? > > > > Yes we can already update the devargs list. > > But this hook will help to do it on hotplug events. > > Do you mean, we will have the udev monitoring framework, and after monitoring > the uevent (hotplug), we want to automatically add a vdev (tap) for that > detected physical device which is managed by kernel?
Yes, we get the hotplug event first. Then the kernel may manage it. And at last, the DPDK hook decide to connect a vdev to it. Note that it would work for other vdevs like af_packet or pcap. > Considering the scan hook is added in bus->parse(), how this can happen > automatically? The hook is in bus->scan(). I think we should launch a bus scan when there is a new device event.
