[dpdk-dev] kernel binding of devices + hotplug

[Matan Azrad]

Hi Stephen

From: Stephen Hemminger, Monday, April 16, 2018 8:19 PM
> On Mon, 16 Apr 2018 17:10:09 +0000
> Matan Azrad <matan at 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 at 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.

This is the same model of the user:
The user knows what DPDK does regarding to binding so he just takes it into account. The same as he knows that the device is used by the DPDK and take it into account.


> 
> >
> > > 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.

And? How it is relevant to the binding discussion?