Re: [dpdk-dev] 2.3 Roadmap

[Kyle Larose <eomereadig@gmail.com>]

On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall <mhall@mhcomputing.net> wrote:


> I am planning to use this to do the captures so you don't incur the headache
> or performance issues with rte_kni.
>
> I am curious how I might be able to link it up w/ the standard libpcap based
> tools to get an end-to-end solution with minimal loss

Earlier Stephen mentioned using the named pipe behaviour of tcpdump.
Is there an opportunity to take what you have mentioned here and marry
it to the named pipe output to get the perf you need?

Personally I have written a tool which sends packets out of a ring pmd
in my main application. The associated rings are polled by another
application which dumps to the packets to a pcap file. This has fairly
good performance, though my implementation is quite crude. My point
here is that sending to a named pipe may not be a bad idea. I don't
know how the perf would compare, but it can't be that bad, can it? :P
Things might get tricky thought if we need multiple queues to handle
the rate of traffic being captured. Not sure how tcpdump would like
that.

I've also considered using cuse to expose a cdev that tcpdump could
read from, but I'm not sure that tcpdump has that ability yet.


>
> Matthew.

Thanks,

Kyle