Re: [PATCH v2 08/12] kni: disabled by default

On Thu, Jun 15, 2017 at 02:09:41PM +0100, Ferruh Yigit wrote:

On 6/9/2017 10:06 AM, Gaëtan Rivet wrote:

quoted

Hi Ferruh,

On Fri, Jun 09, 2017 at 09:56:14AM +0100, Ferruh Yigit wrote:

quoted

On 6/8/2017 12:59 AM, Gaetan Rivet wrote:

quoted

Signed-off-by: Gaetan Rivet <redacted>
---
 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)

quoted

quoted

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?

quoted

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