[dpdk-dev] 2.3 Roadmap

[Aaron Conole]

Bruce Richardson <bruce.richardson at 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