From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DFFAD8E9E for ; Sat, 23 Jan 2016 17:14:26 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 23 Jan 2016 08:14:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,336,1449561600"; d="scan'208";a="732977775" Received: from bmtallap-mobl1.amr.corp.intel.com ([10.254.68.134]) by orsmga003.jf.intel.com with SMTP; 23 Jan 2016 08:14:24 -0800 Received: by (sSMTP sendmail emulation); Sat, 23 Jan 2016 08:14:24 -0700 Date: Sat, 23 Jan 2016 08:14:24 -0800 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20160123161423.GB16304@bricha3-MOBL3> References: <1453478442-23000-1-git-send-email-ferruh.yigit@intel.com> <1881890.o9IDb9bZGc@xps13> <20160122165615.GA31579@sivlogin002.ir.intel.com> <8078914.bEBONouQDl@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8078914.bEBONouQDl@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2016 16:14:27 -0000 On Fri, Jan 22, 2016 at 06:15:40PM +0100, Thomas Monjalon wrote: > 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 ;) > One step at a time. :-) I think we all want to get there.