Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor port support

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Monday, September 5, 2016 11:12 AM
> To: Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] lib/librte_port: enable file descriptor
> port support
> 
> 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 <jasvinder.singh@intel.com>
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > ---
> > v2:
> > - fix checkpatch warnings
> 
> 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?
> 
> /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 significantly more generic/has broader applicability than just the TAP device, as it can be used to interface with any file descriptor, not just a TAP file descriptor, e.g. any Linux kernel character device or sockets (probably a small number of sockets), etc. I am sure it will prove itself useful to more people and we'll probably find even more places to use it going forward. Unfortunately, AFAIK this cannot be fitted as a PMD right now due to EAL limitations, as this would be virtual device and the file descriptor ID would have 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 support to IP pipeline app was to serve as a base of performance comparison between TAP and KNI when the same setup is used, but I am sure there are other potential usages for it.