From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 49D5F8D99 for ; Tue, 1 Dec 2015 16:54:50 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 01 Dec 2015 07:54:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,369,1444719600"; d="scan'208";a="862250664" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga002.jf.intel.com with ESMTP; 01 Dec 2015 07:54:32 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by IRSMSX102.ger.corp.intel.com ([169.254.2.251]) with mapi id 14.03.0248.002; Tue, 1 Dec 2015 15:54:02 +0000 From: "Richardson, Bruce" To: Aaron Conole Thread-Topic: [dpdk-dev] 2.3 Roadmap Thread-Index: AQHRLE1Jg5kVwCCOTr635FzIeMmmb562SBBQ Date: Tue, 1 Dec 2015 15:54:01 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03598B72A@IRSMSX103.ger.corp.intel.com> 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> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:54:50 -0000 > -----Original Message----- > From: Aaron Conole [mailto:aconole@redhat.com] > Sent: Tuesday, December 1, 2015 3:31 PM > To: Richardson, Bruce > Cc: Panu Matilainen ; dev@dpdk.org > Subject: Re: [dpdk-dev] 2.3 Roadmap >=20 > 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 >=20 > 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: >=20 > 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.) >=20 > 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. >=20 > -Aaron Once I had a generic file-handling PMD written, I was then considering exte= nding it to work with TUN/TAP too. :-) I think a TAP PMD would be useful for the downstream distros who can't pack= age KNI as it is right now. /Bruce