anybody know dpdk-for-windows repository? there is a uio driver for common NIC,i can modify inf file the project provided and install it.and run some dpdk related test.i want make some customation that it only can installed on some specified NIC. i think mac addess is almost unique .so my question is How to read mac address before the actual driver run the NIC? i only use Intel e1000 ixgbe i40e driver related card,that Intel card is popular and common.
lihe wrote:
anybody know dpdk-for-windows repository? there is a uio driver for common NIC,i can modify inf file the project provided and install it.and run some dpdk related test.i want make some customation that it only can installed on some specified NIC. i think mac addess is almost unique .so my question is How to read mac address before the actual driver run the NIC?
What kinds of things are you doing that need to be done before the
driver starts? Architecturally, there is no way to talk to a device
until its driver is loaded. Are you just making registry entries?
Can’t you do that after the device is running, and if something changes,
restart the device?
That is a little tricky to do. There’s no generic way to read a MAC address without going through a model-specific initialization sequence (AddDevice, mapping IO space). So you can’t generically make a driver that is only installed onto a device with a specific MAC address, since you first need a driver to read the MAC address.
But you do have a few options:
- Change the problem statement so you don’t have to be so strict with the driver. E.g., you can modify the INF to match a single hardware ID; then the UIO will only be used with any device of that exact model, but no other devices.
- Change the UIO driver so that, during initialization, it quietly sniffs the BAR to see what the MAC address is. If it doesn’t like the MAC address, it fails initialization.
- Write a bus driver whose INF matches the i40e hardware ID. In your initialization, check the MAC address. If it’s good, then enumerate a PDO with a different hardware ID for dpdk to use. Otherwise, enumerate a PDO with a hardware ID that matches the normal Intel INF. In both cases, you’ll have to do a fair amount of work to make your PDOs look like “PCI”, so that the driver can get memory mapped IO and interrupts delivered. This is a fair amount of work.
I am guessing that you want to do this because you have 2 ethernet ports, and you only want to give one of them over to DPDK? That problem is not completely solved: some IHVs have hardware-specific tricks, but there’s no generic solution that works for all DPDK PMDs. We’ve been considering an approach that runs the regular NDIS driver on the PF, but makes it easy to pop out a VF (not necessarily into a VM; just right into the host) for DPDK to use.
As it happens, I know the people who wrote that driver, and we’re currently trying to estimate the customer interest in DPDK-on-Windows. So if you’d like to share your scenario with us, we can use that information to guide and justify future development on DPDK. If you’re not keen on sharing your scenario publicly, you can also send a mail to dpdkwin at microsoft.com .