From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7664A5595 for ; Wed, 16 Mar 2016 12:07:46 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 16 Mar 2016 04:07:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,344,1455004800"; d="scan'208";a="925239463" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.44]) by fmsmga001.fm.intel.com with SMTP; 16 Mar 2016 04:07:43 -0700 Received: by (sSMTP sendmail emulation); Wed, 16 Mar 2016 11:07:41 +0025 Date: Wed, 16 Mar 2016 11:07:41 +0000 From: Bruce Richardson To: Panu Matilainen Cc: Ferruh Yigit , dev@dpdk.org, David Marchand , Helin Zhang Message-ID: <20160316110740.GA24668@bricha3-MOBL3> References: <1455858349-14639-1-git-send-email-ferruh.yigit@intel.com> <1457522269-2198-1-git-send-email-ferruh.yigit@intel.com> <56E6D9A4.4090705@intel.com> <56E90A9F.4020608@redhat.com> <56E91720.5070607@intel.com> <56E917AD.2060701@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E917AD.2060701@redhat.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v3 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: Wed, 16 Mar 2016 11:07:46 -0000 On Wed, Mar 16, 2016 at 10:22:05AM +0200, Panu Matilainen wrote: > On 03/16/2016 10:19 AM, Ferruh Yigit wrote: > >On 3/16/2016 7:26 AM, Panu Matilainen wrote: > >>On 03/14/2016 05:32 PM, Ferruh Yigit wrote: > >>>On 3/9/2016 11:17 AM, Ferruh Yigit wrote: > >>>>This patch sent to keep record of latest status of the work. > >>>> > >>>> > >>>>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. > >>>> > >>>>Motivation is to simplify slow path data communication. > >>>>Now any application can use this new PMD to send/get data to Linux kernel. > >>>> > >>>>PMD supports two communication methods: > >>>> > >>>>1) KDP kernel module > >>>>PMD initialization functions handles creating virtual interfaces (with help of > >>>>kdp kernel module) and created FIFO. FIFO is used to share data between > >>>>userspace and kernelspace. This is default method. > >>>> > >>>>2) tun/tap module > >>>>When KDP module is not inserted, PMD creates tap interface and transfers > >>>>packets using tap interface. > >>>> > >>>>In long term this patch intends to replace the KNI and KNI will be > >>>>depreciated. > >>>> > >>> > >>>Self-NACK: Will work on another option that does not introduce new > >>>kernel module. > >>> > >> > >>Hmm, care to elaborate a bit? The second mode of this PMD already was > >>free of external kernel modules. Do you mean you'll be just removing > >>mode 1) from the PMD or looking at something completely different? > >> > >>Just thinking that tun/tap PMD sounds like a useful thing to have, I > >>hope you're not abandoning that. > >> > > > >It will be KNI PMD. > >Plan is to have something like KDP, but with existing KNI kernel module. > >There will be tun/tap support as fallback. > > Hum, now I'm confused. I was under the impression everybody hated KNI and > wanted to get rid of it, and certainly not build future solutions on top of > it? > KNI has it's issues - mainly: a) not being upstream and b) having large amounts of code to do port management in it, that is best handled by other means - but the code for transferring packets between kernel space and userspace is more performant and scalable than TUN/TAP, so we need to keep that around unless/until we can get TUN/TAP to reach the same performance levels. Now, we are thinking of some ways in which that can be achieved, but any such solution is going to be a bit out, so making any driver for transferring packets from user->kernel and vice versa might as well take advantage of KNI as well as TUN/TAP so as to allow those who want the extra performance to have it. Regards, /Bruce