On 09/28/2015 09:55 PM, Kay Sievers wrote:
On Mon, Sep 28, 2015 at 8:48 PM, Flavio Leitner <f...@sysclose.org> wrote:
On Mon, Sep 28, 2015 at 08:06:50PM +0200, Kay Sievers wrote:
On Sun, Sep 27, 2015 at 11:37 PM, Flavio Leitner <f...@sysclose.org> wrote:
I am looking for guidance on how to properly resolve driver binding
with systemd (which seems to me the best place to do that).
This seems to be a too exotic and niche use case, nothing
general-purpose enough to implement high-level knobs in systemd.
These alternative drivers might be new yet, so there is no much around
them, but we need to start right to avoid problems in the future.
Accelerated userspace datapath is one use case that changes the default
NIC driver to UIO or VFIO driver. Then you use DPDK applications for
fast packet processing or use DPDK integrated Open vSwitch for switching.
Consider that Open Stack (WIP), Open Shift and maybe containers can use
the above setup, so isn't really a niche use case. It's pretty much a
requirement for NFV projects as well.
As you mention, you could use custom udev rules to actually bind a
specific driver. I don't think we want anything more abstract in
systemd.
The problem with that is we can't stop the service to roll back the
driver. Or more importantly, create a dependency to, let's say,
start Open vSwitch only after the ports are bound to the right driver.
Or start an application that requires the NIC to be bound first.
Sure, I understand all that. I would still call all that a niche and I
still don't think it's systemd's job to solve such a problem.
Well, sure we could easily hack up some DPDK-specific thing for this,
but the need for alternative driver binding is in no way specific to DPDK:
- as explained in https://lwn.net/Articles/143397/, distros might need
to support multiple (versions of) traditional drivers for a single device
- VFIO is used for more than just NIC passthrough in virtualization
So if we go and whip up some DPDK specific hack for this, chances are
it'll evantually clash with something else. That's why we're asking for
opinions how to best implement this in a generic fashion systemd/udev.
- Panu -
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
