[dpdk-dev] [PATCH v2 08/12] kni: disabled by default

[Gaëtan Rivet]

On Thu, Jun 15, 2017 at 02:09:41PM +0100, Ferruh Yigit wrote:
> On 6/9/2017 10:06 AM, Gaëtan Rivet wrote:
> > Hi Ferruh,
> > 
> > On Fri, Jun 09, 2017 at 09:56:14AM +0100, Ferruh Yigit wrote:
> >> On 6/8/2017 12:59 AM, Gaetan Rivet wrote:
> >>> Signed-off-by: Gaetan Rivet <gaetan.rivet at 6wind.com>
> >>> ---
> >>>  config/common_linuxapp | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/config/common_linuxapp b/config/common_linuxapp
> >>> index b3cf41b..cc85cc6 100644
> >>> --- a/config/common_linuxapp
> >>> +++ b/config/common_linuxapp
> >>> @@ -38,7 +38,7 @@ CONFIG_RTE_EXEC_ENV_LINUXAPP=y
> >>>  CONFIG_RTE_EAL_IGB_UIO=y
> >>>  CONFIG_RTE_EAL_VFIO=y
> >>>  CONFIG_RTE_KNI_KMOD=y
> >>> -CONFIG_RTE_LIBRTE_KNI=y
> >>> +CONFIG_RTE_LIBRTE_KNI=n
> >>>  CONFIG_RTE_LIBRTE_PMD_KNI=y
> >>>  CONFIG_RTE_LIBRTE_VHOST=y
> >>>  CONFIG_RTE_LIBRTE_PMD_VHOST=y
> >>>
> >>
> >> Hi Gaetan,
> >>
> >> We shouldn't just disable components that doesn't compile.
> >>
> > 
> > Ah, sure :) . This patch is not meant to be integrated as is, but only
> > as a convenient way for testers to apply the patchset and verify the
> > compilation, as far as KNI is not concerned.
> > 
> > Eventdev and cryptodev fixed this dependency. I was thinking about
> > looking into it for KNI and PDUMP but I don't have the time right now,
> > and I'm not sure I will have until the end of June.
> 
> Moved from another mail thread
> (http://dpdk.org/ml/archives/dev/2017-June/067936.html)
> 
> >> KNI uses / depends pci, I am not sure what to fix here.
> >>
> >> The problem to enable the KNI is build dependency problem, right?
> >>
> >> I guess problem will be fixes if we can build in following order:
> >> - lib/eal
> >> - drivers/bus
> >> - lib
> >> - drivers
> >>
> >> This was the case when bus drives compiled within eal. What do you think
> >> about this build order?
> >>
> >
> > Yes, that build order would fix the issue.
> > However, IMO this is not the proper way to proceed.
> > It obscures the architecture, the distinction between DPDK abstractions
> > and their implementations.
> >
> > Looking quickly into this dependency, it seems that the PCI info is only
> > used during allocation, and only to register PCI information within
> > device infos. They do not seem used afterward at the library level,
> > except to print some device description upon device start.
> >
> > They can be completely removed from KNI (both from the lib and the
> > driver), without breaking the compilation.
> > This however changes the API of rte_kni_alloc() and the ABI of
> > rte_kni_conf.
> 
> PCI info is not only for printing, it is required for ethtool support.
> 

I see. Sorry, I never really looked into it before.

> The pci info sent to KNI kernel module, which uses this information to
> associate kernel driver to DPDK interface. Basically this is required
> for control part support of KNI.
> 
> So I believe we can't just remove this.
> 

Ok, those infos should stay reachable. Do they have to stay at the same
place however?

> > Ideally KNI interfaces should be able to use any rte_device, not only
> > PCI. But if it is forced to use only PCI devices, then pointing to an
> > rte_pci_device seems a better way to proceed, as it has all those infos
> > readily available. It would allow the PCI device to grow and evolve
> > without breaking the KNI lib.
> 
> Ideally this is good idea to make DPDK libraries bus agnostic.
> 
> But for KNI, it is not just lib/librte_kni, it has a kernel module
> counterpart and it needs to know the bus information, in this manner KNI
> is different.
> 
> Even if we assume it is possible to make KNI independent from bus, this
> effort is not very useful because we don't want to continue KNI ethtool
> support as it is (by having Linux NIC drivers in kernel module), so
> there won't be any other NIC that benefits from update.
> 
> And option can be replace KNI ethtool support with KCP, but we are
> struggling to upstream KCP for a while, and this is another story.
> 
> For specific to KNI, we can say, it is a library that is dependent to
> specific bus. I believe build system should be able to support some
> components depends to specific bus.
> 

Would it be feasible to have the same kind of bus-specific interface
that was added for ethdev, cryptodev, eventdev? Having an rte_pci_device
pointer within dev_infos for KNI itself, but setting it while at
the drivers/net/kni level?

The problem is that it breaks KNI API / ABI. But I believe it's possible
this way to reach feature parity while leaving the build order alone.

There may be a compromise, where for this release the build order is
modified only for KNI and fixed in the next, thus respecting the
API change rules in place.

Before that call could be made though, we should first determine whether KNI
is fixable and a proper solution can be reached without impacting the
build order in the long term. Once we have this plan, we can decide whether
the priority is the KNI API and its users or the DPDK arch integrity.

-- 
Gaëtan Rivet
6WIND