[dpdk-dev] kernel binding of devices + hotplug
Burakov, Anatoly
anatoly.burakov at intel.com
Fri Apr 13 19:40:46 CEST 2018
On 13-Apr-18 5:40 PM, Bruce Richardson wrote:
> On Fri, Apr 13, 2018 at 06:31:21PM +0200, Thomas Monjalon wrote:
>> It's time to think (again) how we bind devices with kernel modules.
>> We need to decide how we want to manage hotplugged devices with DPDK.
>>
>> A bit of history first.
>> There was some code in DPDK for bind/unbind, but it has been removed
>> in DPDK 1.7 - http://dpdk.org/commit/5d8751b83
>> Copy of the commit message (in 2014):
>> "
>> The bind/unbind operations should not be handled by the eal.
>> These operations should be either done outside of dpdk or
>> inside the PMDs themselves as these are their problems.
>> "
>>
>> The question raised at this time (4 years ago) is still under discussion.
>> Should we manage binding inside or outside DPDK?
>> Should it be controlled in the application or in the OS base?
>>
>> As you know, we use dpdk-devbind.py.
>> This tool lacks two major features:
>> - persistent configuration
>> - hotplug
>>
>> If we consider that the DPDK applications should be able to apply its own
>> policy to choose the devices to bind, then we need to implement binding
>> in the PMD (with EAL helpers).
>>
>> On the other hand, if we consider that it is the system responsibility,
>> then we could choose systemd/udev and driverctl.
>>
>> The debate is launched!
>>
>
> Allow me to nail my colours to the mast early! :-)
>
> I believe it's system not application responsibility.
> I also believe I have previously explained my reasons for that choice in
> some of the previous email threads.
For what it's worth, I tend to agree, if only because writing code for
what is essentially a bunch of read/write/filesystem enumeration in C is
extremely fiddly and error prone :) IMO things like this are better
handled either by scripts, or by tools whose sole purpose is doing
exactly that (or both).
I like having scripts like devbind in DPDK because we can tailor them to
our use cases better, and having them is amenable to automation, but
while I wouldn't be opposed to removing them altogether in favor of some
external tool (systemd/udev/driverctl/whatever), in my humble opinion
moving them back into EAL or even PMD's would be a mistake.
--
Thanks,
Anatoly
More information about the dev
mailing list