From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH] net/kni: add KNI PMD
Date: Fri, 09 Sep 2016 09:36:16 +0200
Message-ID: <23402357.BqYEcGSZAq@xps13>
References: <1473157994-25101-1-git-send-email-ferruh.yigit@intel.com>
 <1794333.caoKPGO1RT@xps13> <f204ba35-b5e7-4fb5-d51d-5d286dd041db@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org
To: Ferruh Yigit <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id 4587F2C52
 for <dev@dpdk.org>; Fri,  9 Sep 2016 09:36:18 +0200 (CEST)
Received: by mail-wm0-f45.google.com with SMTP id w12so16180557wmf.0
 for <dev@dpdk.org>; Fri, 09 Sep 2016 00:36:18 -0700 (PDT)
In-Reply-To: <f204ba35-b5e7-4fb5-d51d-5d286dd041db@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-09-08 19:11, Ferruh Yigit:
> On 9/8/2016 10:38 AM, Thomas Monjalon wrote:
> > 2016-09-08 10:25, Bruce Richardson:
> >> On Thu, Sep 08, 2016 at 09:44:55AM +0200, Thomas Monjalon wrote:
> >>> 2016-09-06 11:33, Ferruh Yigit:
> >>>> Add KNI PMD which wraps librte_kni for ease of use.
> >>>>
> >>>> KNI PMD can be used as any regular PMD to send / receive packets to the
> >>>> Linux networking stack.
> >>>
> >>> Good move!
> >>> Why not deprecate librte_kni and move all the code in the PMD later?
> >>
> >> +1 to this plan. However, I don't think it all needs to be done in one patchset,
> >> though, does it?
> > 
> > I think the deprecation notice must be in this patchset along with some
> > __rte_deprecated in front of librte_kni functions.
> > Then the move of the library in the PMD could be done in the next release.
> > 
> 
> Not sure about deprecating librte_kni, this means existing KNI
> applications needs to be updated. What is the benefit of this effort?
> 
> Also librte_kni supports more than what PMD does, like PMD doesn't have
> ethtool support or binding kernel threads, it uses hardcoded mbuf_size...
> 
> I was thinking PMD as a data only, simplified use case of library.

OK, thanks for the clarification.