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 D0ECADE6 for ; Wed, 2 Dec 2015 03:42:24 +0100 (CET) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id 5199C1BB; Tue, 1 Dec 2015 21:42:24 -0500 (EST) Date: Tue, 1 Dec 2015 21:42:24 -0500 From: Matthew Hall To: "Wiles, Keith" Message-ID: <20151202024224.GA779@mhcomputing.net> References: <20151130171655.70e4ce25@xeon-e3> <20151201100333.GA32252@bricha3-MOBL3> <565DAE6E.5040102@redhat.com> <565DB356.9060602@6wind.com> <565DB580.9090209@redhat.com> <20151201151941.GA33120@bricha3-MOBL3> <59AF69C657FD0841A61C55336867B5B03598B72A@IRSMSX103.ger.corp.intel.com> <2D75B028-2F4E-43BA-B229-BB4BF2FD5F86@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D75B028-2F4E-43BA-B229-BB4BF2FD5F86@intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Wed, 02 Dec 2015 02:42:25 -0000 On Wed, Dec 02, 2015 at 01:38:07AM +0000, Wiles, Keith wrote: > In Pktgen I used tap interface to wireshark and that worked very nicely the > only problem is it was slow :-( > > Having a tap PMD would be nice to be able to remove that code from Pktgen. All these approaches we discussed so far have a serious architectural issue. The entire point of BPF / libpcap was to prevent crossing unnecessary system boundaries with an arbitrarily, unsustainably large volume of unfiltered packets which will be tossed out anyways thereafter as they are irrelevant to a particular debugging objective. In the past it was the kernel -> user boundary. In our case it is the Data Plane -> Management Plane boundary. If we don't use something similar to libpcap offline mode (which I am using presently in my code) or preferably the user-space bpfjit (which I am working up to using eventually), it's going to be more or less impossible for this to work properly and not blow stuff up with anything close to wirespeed traffic going through the links being monitored. Especially with 10, 40, 100, ad nauseam, gigabit links. With the classic BPF / libpcap, it's absolutely possible to get it to work, without causing a big performance problem, or causing a huge packet dump meltdown, or any other issues in the process. We need to find a way to achieve the same objective in our new environment as well. One possible option, if some kernel guys could assist with figuring out the trick, would be if we could capture the BPF ioctl / syscall / whatever it secretly does on the TAP or KNI interface, when it passes the capture filter to the kernel, and steal the filter for use in pcap offline or userspace bpfjit inside of DPDK. Then supply only the packets meeting the filter back onto said interface. Matthew.