From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by dpdk.org (Postfix) with ESMTP id 0C32237A6 for ; Mon, 14 Dec 2015 22:29:42 +0100 (CET) Received: by obcno2 with SMTP id no2so23502192obc.3 for ; Mon, 14 Dec 2015 13:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XTQ26+aB9LVlFVqrPngphY6qIlHrL1dGcE+aqAv6VOw=; b=n4AT23KDM2ad9Q0jygiIRSnqGWG64MEzLzE/uG6OtV4FoKtkWf49iHpY0BQyxOj3vf /WsQOVJ/njGaKTNi9Uyc6JHm61HMl5bDeI5HLG9kd/m0XCE6rWY43J0bCnScS94Idko2 cmIBrAu4bBKFwDTknVjyPXUwosblIDnPm1wcH54jtXZCQyLlV0/WSxrjyDuwvNiexw8B NN4+PvxpdI25iUjNoKQyTp/DsJXQ87dlFxOBZtncmhbUohXQVSLcBI3Qu8lT2shfMx+1 QIv3/7MNnrpq5Y7JO+s5v00ryzPnV/7sRyU62H6XcpEP164E1jKkA4n8p8tw7VDdYLB0 bOYw== MIME-Version: 1.0 X-Received: by 10.60.17.1 with SMTP id k1mr27018249oed.4.1450128581380; Mon, 14 Dec 2015 13:29:41 -0800 (PST) Received: by 10.76.68.7 with HTTP; Mon, 14 Dec 2015 13:29:41 -0800 (PST) In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> <20151214182931.GA17279@mhcomputing.net> Date: Mon, 14 Dec 2015 16:29:41 -0500 Message-ID: From: Kyle Larose To: Aaron Conole Content-Type: text/plain; charset=UTF-8 Cc: dev@dpdk.org, Morten B Subject: Re: [dpdk-dev] tcpdump support in DPDK 2.3 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 21:29:42 -0000 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 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