On Fri, 16 Jun 2017 16:27:47 +0100 Ferruh Yigit <ferruh.yi...@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.
