From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v3 0/2] slow data path communication between DPDK port and Linux Date: Wed, 16 Mar 2016 08:19:44 +0000 Message-ID: <56E91720.5070607@intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: David Marchand , Helin Zhang To: Panu Matilainen , dev@dpdk.org Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0A3E52934 for ; Wed, 16 Mar 2016 09:19:47 +0100 (CET) In-Reply-To: <56E90A9F.4020608@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 simplific= ation done. >>> >>> Motivation is to simplify slow path data communication. >>> Now any application can use this new PMD to send/get data to Linux ke= rnel. >>> >>> PMD supports two communication methods: >>> >>> 1) KDP kernel module >>> PMD initialization functions handles creating virtual interfaces (wit= h help of >>> kdp kernel module) and created FIFO. FIFO is used to share data betwe= en >>> userspace and kernelspace. This is default method. >>> >>> 2) tun/tap module >>> When KDP module is not inserted, PMD creates tap interface and transf= ers >>> 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. >> >=20 > Hmm, care to elaborate a bit? The second mode of this PMD already was=20 > free of external kernel modules. Do you mean you'll be just removing=20 > mode 1) from the PMD or looking at something completely different? >=20 > Just thinking that tun/tap PMD sounds like a useful thing to have, I=20 > hope you're not abandoning that. >=20 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. Regards, ferruh