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

[Ferruh Yigit <ferruh.yigit@intel.com>]

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

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.

>
> But it seems better than changing the build order and opening a can of
> all kind of worms, allowing a few libraries to skirt around their duty to
> remain generic and independent from abstraction implementations.

I see your point.

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

>
> Anyway, I think there are several possible solutions to this, before
> resorting to modifying the build order.