From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mhall@mhcomputing.net>
Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170])
 by dpdk.org (Postfix) with ESMTP id 99ED637A6
 for <dev@dpdk.org>; Mon, 14 Dec 2015 23:25:28 +0100 (CET)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 25354419; Mon, 14 Dec 2015 17:25:28 -0500 (EST)
Date: Mon, 14 Dec 2015 17:25:28 -0500
From: Matthew Hall <mhall@mhcomputing.net>
To: Aaron Conole <aconole@redhat.com>
Message-ID: <20151214222528.GB21163@mhcomputing.net>
References: <98CBD80474FA8B44BF855DF32C47DC358AF758@smartserver.smartshare.dk>
 <20151214182931.GA17279@mhcomputing.net>
 <f7t7fkglu13.fsf@aconole.bos.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f7t7fkglu13.fsf@aconole.bos.csb>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dev@dpdk.org, Morten B <mb@smartsharesystems.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2015 22:25:28 -0000

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 both pcap and pcap-ng (although -ng support may not be 100%,
> I expect it will get better).

It doesn't do things such as scatter-gather vector IO. So it causes a lot more 
system calls than needed. It's an issue if you are doing I40E and such. But I 
don't really care so much how it works.

> 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.

For me I think it's very important to make something that works even with 
tremendous load, not causing tons of writes and syscalls on packets that match 
no filters and are not even wanted. None of the solutions I saw so far could 
do this except bpfjit combined with extcap.

Matthew.