From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id B10245599 for ; Wed, 16 Mar 2016 11:47:13 +0100 (CET) Received: by mail-wm0-f45.google.com with SMTP id p65so66033315wmp.0 for ; Wed, 16 Mar 2016 03:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=EgUEjZnP/PgM8Bh06zX7ISKpVNjHZqs1bJqozqm3Htk=; b=IQaknC4dVzNIv1+8N///3XhBIHw4qFGkqD5HFWEKkYY/hv+8hWnSApPT5q7vYPVC1/ AYhoisCaARjq0ccyOKm5CXRjF6Qwtn7EdirI4Cb9+8Nbbvfmd2jWG2/I+zDhinUIBkBv 4kTJRIT/3FSapeokSxjmAwWSOI3d/ADR/79welevHgyNK0CBZu0UeCYWs1j8wMQDicwj d6YNh1T/uLOQVlI/mhbg/cQxuoNstH2anyJIWd+plnR04peuyfYxtcLi3zdkoWvUn48q XPk8MKJXuEbXCbeeoTgxxso/0ew9vDkUdeuhRGrnBihz0g4XykrsN1nlpnx9NcW8ClV3 WXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=EgUEjZnP/PgM8Bh06zX7ISKpVNjHZqs1bJqozqm3Htk=; b=U4dSWpNozXbqzTTMClY/VdFj25i6aKeeEOmuBewNj9mFy14nAN60dJ+Es0APWJxINH 7Z0qrWYrYNmCwU5sF6tTBEwzkmcYpD2X1CGwL0vINoZMgpcx7ThyJbORn2Lf65mBDSDU ubW8NE7wlk8peWkw9bYdCY5QMFOhwT+xUO/Ozd7wVe5wvLiRyA8vT7KMFEQQm9v0VuXE /IfQZAQFMOaNaWVcb9UkNJyjV6hImtGHMXwqakUoGaUmVzFrsmvMvjz/hHpZfO/Nk4kM t9TdLwxnYudXYNeIMbj9lTz35vtN5QWkFzO5C0x51h8nHSoUYUAH8QIIe71cycquzDiR MyOA== X-Gm-Message-State: AD7BkJIvGEDzegchhqNIluyp9Kov0nWG4M+l+0GP8FKHllpoDNYtkTd87a6kUC4hO6UIqw4i X-Received: by 10.28.1.199 with SMTP id 190mr3784783wmb.3.1458125233508; Wed, 16 Mar 2016 03:47:13 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id s66sm25086874wmb.6.2016.03.16.03.47.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 03:47:12 -0700 (PDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Panu Matilainen , David Marchand , Helin Zhang Date: Wed, 16 Mar 2016 11:45:45 +0100 Message-ID: <2637434.UE2LQEG9YB@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56E934E5.4080905@intel.com> References: <1455858349-14639-1-git-send-email-ferruh.yigit@intel.com> <56E917AD.2060701@redhat.com> <56E934E5.4080905@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 10:47:13 -0000 2016-03-16 10:26, Ferruh Yigit: > On 3/16/2016 8:22 AM, 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? > > We can't remove it. Why? > We can't replace/improve it -you were one of the major opposition to this. > This doesn't leave more option other than using it. Why cannot we replace it by something upstream? > There won't be any update in KNI kernel module, library + sample app > will be converted into PMD.