On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall <mhall at 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
