Re: [dpdk-dev] tcpdump support in DPDK 2.3

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

On Wed, Dec 16, 2015 at 01:15:57PM -0500, Matthew Hall wrote:
> On Wed, Dec 16, 2015 at 11:56:11AM +0000, Bruce Richardson wrote:
> > Having this work with any application is one of our primary targets here. 
> > The app author should not have to worry too much about getting basic debug 
> > support. Even if it doesn't work at 40G small packet rates, you can get a 
> > lot of benefit from a scheme that provides functional debugging for an app. 
> 
> I think my issue is that I don't think I buy into this particular set of 
> assumptions above.
> 
> I don't think a capture mechanism that doesn't work right in the real use 
> cases of the apps actually buys us much. If all we care about is quickly 
> dumping some frames to a pcap for occasional debugging, I already have some C 
> code for that I can donate which is a lot less complicated than the trouble 
> being proposed for "basic debug support". Or we could use libpcap's 
> equivalent... but it's quite a lot more complicated than the code I have.
> 
> If we're going to assign engineers to this it's costing somebody a lot of time 
> and money. So I'd prefer to get them focused on something that will always 
> work even with high loads, such as real bpfjit support.
> 
> Matthew.

Hi,

I think it basic boils down to the fact that we are trying to solve different
problems. Our current focus is the generic usability of all DPDK applications,
as discussed at the DPDK Userspace Summit. Our plan is to provide some way to
allow standard packet capture apps, such as tcpdump, to be used easily with
DPDK. This is something also being looked for by folks such as those working
on OVS e.g. called out at http://openvswitch.org/pipermail/dev/2015-August/058814.html

  "- Insight into the system and debuggability: nothing beats tcpdump for the
    kernel datapath.  Can something similar be done for the userspace
    datapath?

  - Consistency of the tools: some commands are slightly different for the
    userspace/kernel datapath.  Ideally there shouldn't be any difference."

Providing libraries for packet capture at high packet rates is a related, but
different problem, that we'll maybe look to investigate in the future - assuming
that nobody else solves it first.

/Bruce