On 12/1/15, 10:54 AM, "dev on behalf of Richardson, Bruce" <dev-bounces at dpdk.org on behalf of bruce.richardson at intel.com> wrote:
> > >> -----Original Message----- >> From: Aaron Conole [mailto:aconole at redhat.com] >> Sent: Tuesday, December 1, 2015 3:31 PM >> To: Richardson, Bruce <bruce.richardson at intel.com> >> Cc: Panu Matilainen <pmatilai at redhat.com>; dev at dpdk.org >> Subject: Re: [dpdk-dev] 2.3 Roadmap >> >> 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 > >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. In Pktgen I used tap interface to wireshark and that worked very nicely the only problem is it was slow :-( Having a tap PMD would be nice to be able to remove that code from Pktgen. > >/Bruce > Regards, Keith
