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 B23548D85
 for <dev@dpdk.org>; Tue,  1 Dec 2015 20:32:33 +0100 (CET)
Received: by mail.mhcomputing.net (Postfix, from userid 1000)
 id 381891BB; Tue,  1 Dec 2015 14:32:33 -0500 (EST)
Date: Tue, 1 Dec 2015 14:32:33 -0500
From: Matthew Hall <mhall@mhcomputing.net>
To: Aaron Conole <aconole@redhat.com>
Message-ID: <20151201193233.GB28164@mhcomputing.net>
References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674705F1@IRSMSX108.ger.corp.intel.com>
 <D76BBBCF97F57144BB5FCF08007244A7311148B3@wtl-exchp-2.sandvine.com>
 <20151130171655.70e4ce25@xeon-e3>
 <20151201100333.GA32252@bricha3-MOBL3>
 <565DAE6E.5040102@redhat.com> <565DB356.9060602@6wind.com>
 <565DB580.9090209@redhat.com>
 <20151201151941.GA33120@bricha3-MOBL3>
 <f7tvb8ii3t5.fsf@aconole.bos.csb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f7tvb8ii3t5.fsf@aconole.bos.csb>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] 2.3 Roadmap
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: Tue, 01 Dec 2015 19:32:33 -0000

On Tue, Dec 01, 2015 at 10:31:02AM -0500, Aaron Conole wrote:
> The benefit is no dependancy on kernel modules (just TUN/TAP support). I 
> don't have a way of signaling sampling, so right now, it's just drinking 
> from the firehose.

This is actually quite a good idea. Many years ago I coded up a simple 
connector between DPDK and TAP devices for use with some legacy applications 
that did not support DPDK.

I could definitely connect the output of user-space bpfjit to a TAP device 
quite easily.

I am somewhat less clear on how to connect tcpdump or other standard libpcap 
based entities up, so that one could change the capture filters or other 
settings from outside the DPDK application. I am hoping some of the network 
API experts can comment on this since I'm just a security specialist.

How are you letting people configure the capture filter in this scenario?

Matthew.