DPDK patches and discussions
 help / color / mirror / Atom feed
From: Kyle Larose <eomereadig@gmail.com>
To: Aaron Conole <aconole@redhat.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 16:29:41 -0500	[thread overview]
Message-ID: <CAMFWN9kaSuza_x3qDo_kA+ugcX8szV+UaFB9WB9cDr8ihnyRmA@mail.gmail.com> (raw)
In-Reply-To: <f7t7fkglu13.fsf@aconole.bos.csb>

On Mon, Dec 14, 2015 at 2:17 PM, Aaron Conole <aconole@redhat.com> wrote:

> No need to donate to the cause on this one, I think :) The issues
> surrounding tcpdump are, imo, ones of library/application workflow. HOW
> does the user enable tcpdump-like support? The current option is to
> start up with a pcap PMD configured, capture to a file for a bit, then
> stop. I think the issues being discussed are what other options to give
> the user. Then again, I may have my signals crossed somewhere.
>

I don't think you're crossing signals on giving options to users.
However, I think we're discussing more than just high level UI
options; we're getting into the details internal to any application
involved in capturing packets. While it's great to give options to the
user, we still need to get the captured packets to them. This poses a
few challenges, since we need to do it with low impact(e.g. don't just
write the packet to the HDD in the main packet processing loop), while
not hammering the system with a crazy flood that takes down the kernel
(copy everything to into some critical task). Both of these have been
discussed in earlier threads/earlier in this thread.

To me, these challenges boil down to:
1) Balancing a nice generic output interface with the most efficient
way to get packets out of the application .
2) Filtering as close to the capture point as possible.

Putting that together with giving options, we need to:
1) Give the users a convenient API to start a capture and provide a filter.
2) Balance a nice generic output interface with the most efficient way
to get packets out of the application.
3) Filter as close to the capture point as possible.

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

  reply	other threads:[~2015-12-14 21:29 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 [this message]
2015-12-14 22:36       ` Matthew Hall
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=CAMFWN9kaSuza_x3qDo_kA+ugcX8szV+UaFB9WB9cDr8ihnyRmA@mail.gmail.com \
    --to=eomereadig@gmail.com \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --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).