DPDK is working like a charm, but we are now in the middle of connecting more span ports. Sometimes I want to check some things on a interface with non dpdk tools like ethtool to see info about the sfp or such. After unbinding an interface, loading the required kernel module does not help to find again lets say eth6. How can I trigger RHEL 8/Linux to rediscover this device again?
just to put your process your description into a set of commands (as I understand that):
Let’s say you have i40e with PCIe address e.g. 0000:03:00.0. So your workflow is as:
sudo modprobe vfio-pci
sudo dpdk-devbind -b vfio-pci 0000:03:00.0
- use suricata/dpdk tools
sudo dpdk-devbind -b i40e 0000:03:00.0
- use ethtool but the interface cannot be found there
i40e is just a driver and was just a concrete example of one NIC driver, you might have something else. Also, when probing the vfio-pci driver you might need to enable unsafe mmiou. Do you:
- follow the process as outlined above?
- bind the original driver back when you want to use kernel tools? You mentioned that loading the required kernel module does not help (I think you probably meant binding the req. kernel module but just checking)
- see any (valuable) output when binding the original driver back?
- see that the interface is really bound to the original driver in e.g.
- can confirm that you don’t see it in other tools e.g.
Otherwise, can you provide more info what DPDK version you have, whether it is compiled or installed from the package manager, what NIC/driver do you use?
I haven’t had a chance to run into this issue so we will need to figure this one out by trial and error
Ah interesting, I’m using dpdk-devbind.py -u 0000:03:00.0 to unbind, will give it a try with your process!, and yes this worked:
]# dpdk-devbind.py --bind=vfio-pci 0000:10:00.1
]# suricata shizzle
]# dpdk-devbind.py -b ice 0000:10:00.1
]# ethtool -m eth6
the binding option (
-b) automatically unbinds the current driver and binds the new driver but unbind (
-u) only unbinds the current driver. After
-u option dpdk-devbind leaves the device with no driver bound (so even DPDK wouldn’t work).
Glad I could help.
Sounds more than logical, thanks for your time!