From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id B511958DB for ; Tue, 1 Dec 2015 16:31:04 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id BF329AEF29; Tue, 1 Dec 2015 15:31:03 +0000 (UTC) Received: from aconole.bos.csb (dhcp-25-217.bos.redhat.com [10.18.25.217]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB1FV2BV015710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Dec 2015 10:31:03 -0500 From: Aaron Conole To: Bruce Richardson References: <26FA93C7ED1EAA44AB77D62FBE1D27BA674705F1@IRSMSX108.ger.corp.intel.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> Date: Tue, 01 Dec 2015 10:31:02 -0500 In-Reply-To: <20151201151941.GA33120@bricha3-MOBL3> (Bruce Richardson's message of "Tue, 1 Dec 2015 15:19:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 15:31:05 -0000 Bruce Richardson writes: > On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote: >> On 12/01/2015 04:48 PM, Vincent JARDIN wrote: >> >On 01/12/2015 15:27, Panu Matilainen wrote: >> >>The problem with that (unless I'm missing something here) is that KNI >> >>requires using out-of-tree kernel modules which makes it pretty much a >> >>non-option for distros. >> > >> >It works fine with some distros. I do not think it should be an argument. >> >> Its not a question of *working*, its that out-of-tree kernel modules are >> considered unsupportable by the kernel people. So relying on KNI would make >> the otherwise important and desireable tcpdump feature non-existent on at >> least Fedora and RHEL where such modules are practically outright banned by >> distro policies. >> >> - Panu - > > Yes, KNI is a bit of a problem right now in that way. > > How about a solution which is just based around the idea of setting up a generic > port mirroring callback? Hopefully in the future we can get KNI > exposed as a PMD, > and we already have a ring PMD, and could possibly do a generic file/fifo PMD. > Between the 3, we could then have multiple options for intercepting traffic > going in/out of an app. The callback would just have to copy the traffic to the > selected interface before returning it to the app as normal? > > /Bruce I'm actually working on a patch series that uses a TAP device (it's currently been only minorly tested) called back from the port input. 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. Nothing I'm ready to put out publicly (because it's ugly - just a PoC), but it allows a few things: 1) on demand on/off using standard linux tools (ifconfig/ip to set tap device up/down) 2) Can work with any tool which reads off of standard linux interfaces (tcpdump/wireshark work out of the box, but you could plug in any pcap or non-pcap tool) 3) Doesn't require changes to the application (no command line switches during startup, etc.) As I said, I'm not ready to put it out there publicly, because I haven't had a chance to check the performance, and it's definitely not following any kind of DPDK-like coding style. Just wanted to throw this out as food for thought - if you think this approach is worthwhile I can try to prioritize it, at least to get an RFC series out. -Aaron