From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 43FA5379B for ; Fri, 9 Sep 2016 23:20:00 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP; 09 Sep 2016 14:19:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,307,1470726000"; d="scan'208";a="1048040111" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga002.jf.intel.com with ESMTP; 09 Sep 2016 14:19:58 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.71]) by IRSMSX109.ger.corp.intel.com ([169.254.13.24]) with mapi id 14.03.0248.002; Fri, 9 Sep 2016 22:19:57 +0100 From: "Dumitrescu, Cristian" To: "Richardson, Bruce" , "Singh, Jasvinder" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support Thread-Index: AQHSBrjy7OpFivKxzkSB1gKv0HAAY6BqncKAgAcPp5A= Date: Fri, 9 Sep 2016 21:19:57 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912647A67934@IRSMSX108.ger.corp.intel.com> References: <1470432064-59047-1-git-send-email-jasvinder.singh@intel.com> <1472999921-43283-1-git-send-email-jasvinder.singh@intel.com> <20160905101218.GA18384@bricha3-MOBL3> In-Reply-To: <20160905101218.GA18384@bricha3-MOBL3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDY5YTVkM2MtNWMyMi00NWExLWFmNGUtODk3YmM5MTA0MDVkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InRvaUlxbkZnOW9aVThWZzh2ZGpDcjB2Z3I0YWc1UlZ5Q2NtOFVROGVQZ1k9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support 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: Fri, 09 Sep 2016 21:20:00 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Monday, September 5, 2016 11:12 AM > To: Singh, Jasvinder > Cc: dev@dpdk.org; Dumitrescu, Cristian > Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descr= iptor > port support >=20 > On Sun, Sep 04, 2016 at 03:38:39PM +0100, Jasvinder Singh wrote: > > This patch adds File Descriptor(FD) port type (e.g. TAP port) to the > > packet framework library that allows interface with the kernel network > > stack. The FD port APIs are defined that allow port creation, writing > > and reading packet from the kernel interface. > > > > Signed-off-by: Jasvinder Singh > > Acked-by: Cristian Dumitrescu > > --- > > v2: > > - fix checkpatch warnings >=20 > Rather than adding a special TAP port for use by packet framework alone, > why not > create a TAP PMD/ethdev and then it can be used both by regular DPDK > apps, as well > as by packet framework too - since packet framework already has an ethdev > port > type that presumably works with all ethdevs? >=20 > /Bruce Great idea, but we don't have the bandwidth to create a TAP PMD right now. = Any volunteers? Please also note that the non-blocking file descriptor is actually signific= antly more generic/has broader applicability than just the TAP device, as i= t can be used to interface with any file descriptor, not just a TAP file de= scriptor, e.g. any Linux kernel character device or sockets (probably a sma= ll number of sockets), etc. I am sure it will prove itself useful to more p= eople and we'll probably find even more places to use it going forward. Unf= ortunately, AFAIK this cannot be fitted as a PMD right now due to EAL limit= ations, as this would be virtual device and the file descriptor ID would ha= ve to be known before the DPDK application is started and passed to the app= through the EAL vdev parameter, right? This being said, I propose we go ahead with this new type of port. Whenever= a TAP PMD becomes available, I don't mind changing the IP pipeline app to = use it if people would prefer it. Our primary motivation for adding TAP sup= port to IP pipeline app was to serve as a base of performance comparison be= tween TAP and KNI when the same setup is used, but I am sure there are othe= r potential usages for it.