multiple devices, single driver

[Alexander Boettcher]

Hi Joel

On 25.10.18 17:14, Joel Nider wrote:
>>> I will give you my situation as a specific example. I am writing a 
> driver 
>>> for a PCIe attached NIC (x86 platform). Let us say that I have 2 
> physical 
>>> NICs in my machine with the same device ID and vendor ID. I have 
> specified 
>>> in my config file that I have a driver called "nic_drv", without 
>>> specifying the PCIe address (copied from the example in 
>>> repos/os/run/ping.run).
>>>
>>> When the driver starts, I can enumerate the PCIe devices through the 
>>> Platform::Connection object that is instantiated from the 'env' 
> object. I 
>>> see all PCIe devices of class 'NET' (even other NICs that I don't want 
> my 
>>> driver to handle). So far so good. I can filter through the devices by 
> 
>>> requesting the capability (with Platform::Device_client) and I can 
> read 
>>> the device ID and vendor ID and pick the devices I want to handle.
>>
>> Actually, in this case, I would not encourage to implement it in one
>> driver. The network cards are independent (as opposed for devices on a
>> ahci controller) from each other, so just start/instantiate the driver
>> two times. With that you cleanly isolate the network data.
> 
> Does that mean the memory is duplicated? Two code segments, two execution 
> threads, two address spaces?

Yes. Effectively you can trade memory(+bit of CPU time) with isolation
and robustness.

Imagine your driver is handling 8 (or more) identical network cards, and
the driver fails for some reason. Your 8 network links are down until
you restart the driver on the fly.

In contrast, if you have 8 network driver instances, one failure of one
driver has no effect to the other 7 network links. The downtime of the
other links are -zero- and you have just to bring up one network card
driver again.
Additionally, no network traffic can "accidentally" leak between the
network links.
Furthermore, if required, the placement of the multiple driver instances
on specific cores (e.g. pinning) becomes obvious - and easy.

At the end, I think that the driver code will become much easier to read
and to grasp and this will pay off later during maintenance time.

Of course, if you are running in a embedded setup and can't effort, say
less than 1M per driver instance, maybe the decision is different.

Cheers,

Alex.
-- 
Alexander Boettcher
Genode Labs

https://www.genode-labs.com - https://www.genode.org

Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth