[dpdk-dev] [RFC] Kernel Control Path (KCP)

Ferruh Yigit ferruh.yigit at intel.com
Fri Jun 16 17:27:47 CEST 2017


Hi Alex,

On 6/15/2017 1:07 PM, Alex Rosenbaum wrote:
> please excuse me if I missed out of the previous conversation and
> asking these questions again...
> 
> Why create a new driver instead of improving the existing KNI driver?

For control path, KNI uses Linux kernel driver within KNI kernel module.
This method works, but may not be best option, and technically not
extendable for some drivers. KNI control path currently supports only
two drivers, proposed KCP works for all PMDs by default.

Overall, KCP is outcome of the effort of improving KNI control path.

Initial proposal was (a year ago I guess) introducing two new modules,
one for control path and one for data path, and replace KNI completely.
But current target is have KCP to have better control path support.

Also, KNI handles both data and control path. But both are different
functionalities and not need to be in some module. For example an
application may not need exception data path to kernel, but may be
interested in controlling DPDK interfaces via common Linux tools.

> Can you share a table of the differences between the two driver /
> approaches [KNI vs KCP]?

KCP differences against KNI:

- KCP is only for control path
- Linux virtual interfaces created automatically, without DPDK
application modification.
- To create/destroy interfaces KCP uses rtnl, KNI uses ioctl. So
technically it is possible to use "ip" tool to create / destroy
interfaces supported by KCP.
- KCP kernel module and userspace counterpart communicates via netlink,
KNI uses ioctl.
- KCP works for all PMDs without update on PMDs.

> 
> Why do you want to remove features like data path that is provided by KNI today?

There is not intention to remove exception data path, the focus is to
improve KNI.

> 
> thanks,
> Alex
> 



More information about the dev mailing list