From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [RFC 0/2] slow data path communication between DPDK
	port and Linux
Date: Fri, 22 Jan 2016 18:15:40 +0100
Message-ID: <8078914.bEBONouQDl@xps13>
References: <1453478442-23000-1-git-send-email-ferruh.yigit@intel.com>
 <1881890.o9IDb9bZGc@xps13> <20160122165615.GA31579@sivlogin002.ir.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Ferruh Yigit <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
 by dpdk.org (Postfix) with ESMTP id EF5FD5A44
 for <dev@dpdk.org>; Fri, 22 Jan 2016 18:16:41 +0100 (CET)
Received: by mail-wm0-f51.google.com with SMTP id b14so142777678wmb.1
 for <dev@dpdk.org>; Fri, 22 Jan 2016 09:16:41 -0800 (PST)
In-Reply-To: <20160122165615.GA31579@sivlogin002.ir.intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2016-01-22 16:56, Ferruh Yigit:
> On Fri, Jan 22, 2016 at 05:31:45PM +0100, Thomas Monjalon wrote:
> > Hi Ferruh,
> > 
> > Not commenting the implementation, just the method.
> > 
> > 2016-01-22 16:00, Ferruh Yigit:
> > > This is slow data path communication implementation based on existing KNI.
> > > Difference is: librte_kni converted into a PMD, kdp kernel module is almost
> > > same except all control path functionality removed and some simplification done.
> > 
> > Is there a chance to submit such kernel module on LKML instead of DPDK?
> > We should avoid maintaining some out-of-tree modules.
> 
> The ones I have sent are not generic enough to be in Linux tree.

I've not read the details.
What is missing to be generic?

> We already maintain kni kernel module,

Yes it is painful and not accepted in some Linux distros.

> these patches are part of effort to make
> kni more maintainable, by separation of concerns, removing network drivers from it,
> and simplifying some of code.

Your patch is not removing KNI unfortunately ;)

> For this patch set, tun/tap interface can be alternative, and it looks like it
> removes out-of-tree kernel module requirement, unless people want current
> FIFO implementation because of better performance.
> 
> For control path, unfortunately I am not aware of any solution without out-of-tree
> kernel module support.
> 
> Thanks,
> ferruh