Re: [dpdk-dev] 2.3 Roadmap

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Aaron Conole [mailto:aconole@redhat.com]
> Sent: Tuesday, December 1, 2015 3:31 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
> 
> Bruce Richardson <bruce.richardson@intel.com> writes:
> > On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote:
> >> On 12/01/2015 04:48 PM, Vincent JARDIN wrote:
> >> >On 01/12/2015 15:27, Panu Matilainen wrote:
> >> >>The problem with that (unless I'm missing something here) is that
> >> >>KNI requires using out-of-tree kernel modules which makes it pretty
> >> >>much a non-option for distros.
> >> >
> >> >It works fine with some distros. I do not think it should be an
> argument.
> >>
> >> Its not a question of *working*, its that out-of-tree kernel modules
> >> are considered unsupportable by the kernel people. So relying on KNI
> >> would make the otherwise important and desireable tcpdump feature
> >> non-existent on at least Fedora and RHEL where such modules are
> >> practically outright banned by distro policies.
> >>
> >> 	- Panu -
> >
> > Yes, KNI is a bit of a problem right now in that way.
> >
> > How about a solution which is just based around the idea of setting up
> > a generic port mirroring callback? Hopefully in the future we can get
> > KNI exposed as a PMD, and we already have a ring PMD, and could
> > possibly do a generic file/fifo PMD.
> > Between the 3, we could then have multiple options for intercepting
> > traffic going in/out of an app. The callback would just have to copy
> > the traffic to the selected interface before returning it to the app as
> normal?
> >
> > /Bruce
> 
> I'm actually working on a patch series that uses a TAP device (it's
> currently been only minorly tested) called back from the port input. The
> benefit is no dependancy on kernel modules (just TUN/TAP support). I don't
> have a way of signaling sampling, so right now, it's just drinking from
> the firehose. Nothing I'm ready to put out publicly (because it's ugly -
> just a PoC), but it allows a few things:
> 
> 1) on demand on/off using standard linux tools (ifconfig/ip to set tap
>    device up/down)
> 2) Can work with any tool which reads off of standard linux interfaces
>    (tcpdump/wireshark work out of the box, but you could plug in any
>    pcap or non-pcap tool)
> 3) Doesn't require changes to the application (no command line switches
>    during startup, etc.)
> 
> As I said, I'm not ready to put it out there publicly, because I haven't
> had a chance to check the performance, and it's definitely not following
> any kind of DPDK-like coding style. Just wanted to throw this out as food
> for thought - if you think this approach is worthwhile I can try to
> prioritize it, at least to get an RFC series out.
> 
> -Aaron

Once I had a generic file-handling PMD written, I was then considering extending
it to work with TUN/TAP too. :-)
I think a TAP PMD would be useful for the downstream distros who can't package
KNI as it is right now.

/Bruce