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

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 16 Jun 2017 16:27:47 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

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

Hopefully KCP can be submitted for upstream kernel, and therefore be supportable over
the long term. KNI in its current form is not acceptable upstream for a number
of reasons: style, use of ioctl, races with control operations, etc.