From: Matthew Hall <mhall@mhcomputing.net>
To: Kyle Larose <eomereadig@gmail.com>
Cc: dev@dpdk.org, Morten B <mb@smartsharesystems.com>
Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3
Date: Mon, 14 Dec 2015 17:36:13 -0500 [thread overview]
Message-ID: <20151214223613.GC21163@mhcomputing.net> (raw)
In-Reply-To: <CAMFWN9kaSuza_x3qDo_kA+ugcX8szV+UaFB9WB9cDr8ihnyRmA@mail.gmail.com>
On Mon, Dec 14, 2015 at 04:29:41PM -0500, Kyle Larose wrote:
> I've seen lots of ideas and options tossed around which would solve
> some or all of the above items, but nobody actually committing to
> anything. What can we do to actually agree on a solution to go and
> implement? I'm relatively new to the community, so I don't really know
> how this stuff works. Do people typically form a working group where
> they go off and discuss the problem, and then come back to the main
> community with a proposal? Or do people just submit RFCs independently
> with their own ideas?
>
> Thanks,
> Kyle
I am getting the impression of a misplaced sense of urgency / panic. I don't
think anybody came up with a reason why we have to answer all these questions
tremendously quickly. It will take some more time, particularly with the
holidays, for the developers to finish the last bug fixes on the current
release before they have time to discuss 2.3 features.
When that happens, someone working on DPDK full time will be identified as the
leader for the feature, that will lead the effort on PCAP, and help us
formulate the plan. Until then, what we really could use at this point is not
necessarily more writings and speculation, but an answer on some key tech
questions, particularly from some kernel guys:
1) How do we get the pcap filter string and/or BPF opcode vector from libpcap
/ tcpdump / tshark / wireshark, into the DPDK application? There we can
compile it using the user-space bpfjit, so we can filter the packets at very
high speeds and not end up breaking everything doing a ton of stupid copies
when somebody does a capture of one flow on his i40e device or such. libpcap
is crappy about this, as it sends it all over syscalls which are always
assuming the kernel is on the other end, which is a bad assumption on their
part but many decades old and not so easy to fix.
2) How do we get the matched packets back out to the extcap or libpcap? From
what I saw extcap is tshark / wireshark only, which are 1) GPL licensed in
various ways, 2) not as widely used as libpcap. So using only extcap might be
kind of crappy.
3) For libpcap to work, maybe it will help if some of our kernel guys can help
us find out how to "detect" the kernel put a BPF capture filter onto a TUN /
TAP interface, and copy that filter to the DPDK app. Then, take any matched
packets and write them back onto the TUN / TAP. This would also be super
efficient and work with more off-the-shelf tools besides just tshark /
wireshark.
If we don't find the answers for these items I don't think we have a path to a
working solution, forgetting about all the nice-to-have points such as UX
issues, troubleshooting, debugging, etc.
Matthew.
next prev parent reply other threads:[~2015-12-14 22:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 9:57 Morten Brørup
2015-12-14 15:45 ` Aaron Conole
2015-12-14 15:48 ` Thomas Monjalon
2015-12-14 18:29 ` Matthew Hall
2015-12-14 19:14 ` Stephen Hemminger
2015-12-14 22:23 ` Matthew Hall
2015-12-14 19:17 ` Aaron Conole
2015-12-14 21:29 ` Kyle Larose
2015-12-14 22:36 ` Matthew Hall [this message]
2015-12-16 10:45 ` Bruce Richardson
2015-12-16 11:37 ` Arnon Warshavsky
2015-12-16 11:56 ` Morten Brørup
2015-12-16 11:40 ` Morten Brørup
2015-12-16 11:56 ` Bruce Richardson
2015-12-16 12:26 ` Morten Brørup
2015-12-16 13:12 ` Bruce Richardson
2015-12-16 22:45 ` Morten Brørup
2015-12-16 23:38 ` Matthew Hall
2015-12-17 5:59 ` Arnon Warshavsky
2015-12-16 18:15 ` Matthew Hall
2015-12-21 15:39 ` Bruce Richardson
2015-12-21 16:08 ` Morten Brørup
2015-12-21 16:17 ` Gray, Mark D
2015-12-21 17:22 ` Matthew Hall
2015-12-21 16:11 ` Gray, Mark D
2015-12-14 22:25 ` Matthew Hall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151214223613.GC21163@mhcomputing.net \
--to=mhall@mhcomputing.net \
--cc=dev@dpdk.org \
--cc=eomereadig@gmail.com \
--cc=mb@smartsharesystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).