Re: [dpdk-dev] kernel binding of devices + hotplug

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 16 Apr 2018 17:10:09 +0000
Matan Azrad <matan@mellanox.com> wrote:

> Hi Stephen
> 
> From: Stephen Hemminger, Monday, April 16, 2018 7:57 PM
> > On Mon, 16 Apr 2018 16:11:12 +0000
> > Matan Azrad <matan@mellanox.com> wrote:
> >   
> > > > If the device management is only managed in one place, i.e. not in
> > > > DPDK, then there is no conflict to manage.  
> > >
> > > I can't agree with this statement,
> > > The essence of DPDK is to give a good alternative to managing network
> > > devices, DPDK actually takes a lot of management area to manage by
> > > itself to do the user life better :)  
> > 
> > More is not better! DPDK is poorly integrated into Linux overall system. Doing
> > more in DPDK makes this worse not better.  
> 
> In this case I think that yes, more is better.
> Please explain why do you think that in this case it is worse.

DPDK should work with udev, not try and replace functionality that is
already done by udev and systemd. Having a parallel and different model
makes life harder for users.

>  
> > Buried under this discussion is the fact that the Mellanox bifurcated driver
> > behaves completely differently from every other driver. This makes coming
> > to a common solution much harder. The bifurcated model has advantages
> > and disadvantages, in this case it is a disadvantage since it is not easy to
> > manage usage when it is a shared resource.  
> 
> Sorry, what is your point?

The bifurcated model does not play well with driverctl. It just works differently
than other drivers. The bifurcated model works better for simple case of shared
device on bare metal; but it is harder for the transparent bonding model
used on Azure. The eth device is not really available for direct use in kernel;
and there is discussion in netdev about hiding it as well which will break
more things here.