From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 297D558CF for ; Mon, 21 Dec 2015 16:39:50 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 21 Dec 2015 07:39:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,460,1444719600"; d="scan'208";a="712099769" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.65]) by orsmga003.jf.intel.com with SMTP; 21 Dec 2015 07:39:46 -0800 Received: by (sSMTP sendmail emulation); Mon, 21 Dec 2015 15:39:46 +0025 Date: Mon, 21 Dec 2015 15:39:45 +0000 From: Bruce Richardson To: Matthew Hall Message-ID: <20151221153945.GA12016@bricha3-MOBL3> References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk> <20151214182931.GA17279@mhcomputing.net> <20151214223613.GC21163@mhcomputing.net> <20151216104502.GA10020@bricha3-MOBL3> <98CBD80474FA8B44BF855DF32C47DC358AF76F@smartserver.smartshare.dk> <20151216115611.GB10020@bricha3-MOBL3> <20151216181557.GA16963@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216181557.GA16963@mhcomputing.net> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= 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, 21 Dec 2015 15:39:50 -0000 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