From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id DF03BA6A for ; Wed, 16 Dec 2015 19:15:59 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 2DEE1FA; Wed, 16 Dec 2015 13:15:57 -0500 (EST) Date: Wed, 16 Dec 2015 13:15:57 -0500 From: Matthew Hall To: Bruce Richardson Message-ID: <20151216181557.GA16963@mhcomputing.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151216115611.GB10020@bricha3-MOBL3> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 16 Dec 2015 18:16:00 -0000 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.