I noticed a discussion about support for tcpdump in DPDK 2.3.
Please consider which scenarios you want to support:
1. Compatibility with legacy non-DPDK applications (e.g. a DHCP server
application) that captures specific packets by opening RAW sockets and
attaching BPF filters to these soc
Morten Br?rup writes:
> I noticed a discussion about support for tcpdump in DPDK 2.3.
>
>
>
> Please consider which scenarios you want to support:
Morten,
Thanks for your input here. I think there's a different way of
approaching this: "debuggability" (sorry, it's not grammatical).
The end go
2015-12-14 10:45, Aaron Conole:
> After all, it's a networking stack, right?
No, not currently.
DPDK allows to build some specific lightweight or more complete stacks.
FYI your last name comes in as a corrupt character for me. You might have to
think about converting it from ISO 8859-1 / 8859-15 to UTF-8.
On Mon, Dec 14, 2015 at 10:57:10AM +0100, Morten B wrote:
> Check out the new "extcap" feature of Wireshark. It uses named pipes for the
> packets, already m
On Mon, 14 Dec 2015 13:29:31 -0500
Matthew Hall wrote:
> FYI your last name comes in as a corrupt character for me. You might have to
> think about converting it from ISO 8859-1 / 8859-15 to UTF-8.
>
> On Mon, Dec 14, 2015 at 10:57:10AM +0100, Morten B wrote:
> > Check out the new "extcap" feat
Matthew Hall writes:
>> The pcap file format contains a header in front of each packet, which is
>> extremely simple. But it has a timestamp (which uses 32 bit for tv_sec and
>> tv_usec in files), so it needs to be considered how to handle this
>> efficiently.
>
> I already wrote some C code fo
On Mon, Dec 14, 2015 at 2:17 PM, Aaron Conole 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 confi
On Mon, Dec 14, 2015 at 11:14:42AM -0800, Stephen Hemminger wrote:
> There are already several BPF libraries available. I would prefer DPDK not
> start copying existing code.
I didn't copy or reduplicate any code. I was planning to use bpfjit from Alex
Nasonov, but a userspace version instead of
On Mon, Dec 14, 2015 at 02:17:12PM -0500, Aaron Conole wrote:
> Why not just use libpcap to write out pcap files? I bet it does a better
> job that any of us will ;) It's BSD licensed, so there should be no
> issues with linking against it (DPDK currently does for the pcap PMD), and
> it supports b
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
On Mon, Dec 14, 2015 at 05:36:13PM -0500, Matthew Hall wrote:
> 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
2 points from our experience in saving pcap files from a dpdk 10G fire hose:
1)
Our capture module provides a small "bit-vector" to the code that handles
the packets.
Since our packet processing code is already finding out basic stuff about
the packet traversing it (is it IPv4? v6? is it TCP? is
Bruce,
This doesn't really sound like tcpdump to me; it sounds like port mirroring.
Your suggestion is limited to physical ports only, and cannot be attached
further inside the application, e.g. for mirroring packets related to a
specific VLAN.
Furthermore, it doesn't sound like the filtering
On Wed, Dec 16, 2015 at 12:40:43PM +0100, Morten Br?rup wrote:
> Bruce,
>
> This doesn't really sound like tcpdump to me; it sounds like port mirroring.
It's actually a bit of both, in my opinion, it's designed to allow basic
mirroring
of traffic on a port to allow that traffic to be sent to a t
gt;
From: Arnon Warshavsky [mailto:ar...@qwilt.com]
Sent: 16. december 2015 12:37
To: Bruce Richardson
Cc: Matthew Hall; dev at dpdk.org; Morten Br?rup
Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3
2 points from our experience in saving pcap files from a dpdk 10G fire hose:
1)
Our ca
Richardson [mailto:bruce.richard...@intel.com]
Sent: 16. december 2015 12:56
To: Morten Br?rup
Cc: Matthew Hall; Kyle Larose; dev at dpdk.org
Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3
On Wed, Dec 16, 2015 at 12:40:43PM +0100, Morten Br?rup wrote:
> Bruce,
>
> This doesn'
ss than line rate i.e. for functional testing.
For full line rate introspection, we'll have to see when we get some working
code.
/Bruce
>
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
> Sent: 16. december 2015 12:56
> To: Morten
On Wed, Dec 16, 2015 at 11:56:11AM +, 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
>
d...@intel.com]
Sent: 16. december 2015 14:13
To: Morten Br?rup
Cc: Matthew Hall; Kyle Larose; dev at dpdk.org
Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3
On Wed, Dec 16, 2015 at 01:26:11PM +0100, Morten Br?rup wrote:
> Bruce,
>
> Please note that tcpdump is a stupid name for a
On Wed, Dec 16, 2015 at 11:45:46PM +0100, Morten Br?rup wrote:
> Matthew presented a very important point a few hours ago: We don't need
> tcpdump support for debugging the application in a lab; we already have
> plenty of other tools for debugging what we are developing. We need tcpdump
> suppo
Filtering and serializing are 2 different components.
No need to bind them by default, and nothing prevents you from calling them
both from the same context if that what works for your use case.
On Thu, Dec 17, 2015 at 1:38 AM, Matthew Hall wrote:
> On Wed, Dec 16, 2015 at 11:45:46PM +0100, Mor
On Wed, Dec 16, 2015 at 01:15:57PM -0500, Matthew Hall wrote:
> On Wed, Dec 16, 2015 at 11:56:11AM +, 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
> > suppor
Original Message-
From: Bruce Richardson [mailto:bruce.richard...@intel.com]
Sent: 21. december 2015 16:40
To: Matthew Hall
Cc: Morten Br?rup; Kyle Larose; dev at dpdk.org
Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3
On Wed, Dec 16, 2015 at 01:15:57PM -0500, Matthew Hall wrote:
> On Wed, Dec
> 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 don
> Bruce,
>
> Please reconsider your interpretation of the word "debuggability".
> Debugging is not only something that R&D staff does in a lab. Debuggability
> can also be interpreted as a network engineer's ability to debug what is
> happening in a production network.
Is tcpdump used in large pr
On Mon, Dec 21, 2015 at 04:17:26PM +, Gray, Mark D wrote:
> Is tcpdump used in large production cloud environments? I would have
> thought other less intrusive (and less manual) tools would be used? Isn't
> that one of the benefits of SDN.
tcpdump, tshark, wireshark, libpcap, etc. have been u
26 matches
Mail list logo
