From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgwkm04.jp.fujitsu.com (mgwkm04.jp.fujitsu.com [202.219.69.171]) by dpdk.org (Postfix) with ESMTP id C22778D86 for ; Tue, 1 Dec 2015 12:26:45 +0100 (CET) Received: from kw-mxoi1.gw.nic.fujitsu.com (unknown [192.168.231.131]) by mgwkm04.jp.fujitsu.com with smtp id 518e_08e2_e34bce41_eda4_40b8_a3bd_58478fc78e08; Tue, 01 Dec 2015 20:26:42 +0900 Received: from m3050.s.css.fujitsu.com (msm.b.css.fujitsu.com [10.134.21.208]) by kw-mxoi1.gw.nic.fujitsu.com (Postfix) with ESMTP id C5A78AC01A6 for ; Tue, 1 Dec 2015 20:26:41 +0900 (JST) Received: from localhost (unknown [10.17.141.41]) by m3050.s.css.fujitsu.com (Postfix) with ESMTP id 84C17183; Tue, 1 Dec 2015 20:26:41 +0900 (JST) Date: Tue, 01 Dec 2015 20:26:39 +0900 (JST) Message-Id: <20151201.202639.45956937.shin@lenovo> To: bruce.richardson@intel.com From: Yoshinobu Inoue In-Reply-To: <20151201100333.GA32252@bricha3-MOBL3> References: <20151130171655.70e4ce25@xeon-e3> <20151201100333.GA32252@bricha3-MOBL3> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable 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 11:26:46 -0000 Hello DPDK list, I've been so far just roughly reading messages, as I've been working on my company's product based on DPDK1.6 for some time and haven't yet much catched up to newer releases, but as I implemented packet capture for my product just in a way as commented here, (using KNI), > Our current thinking is to use kni to mirror packets into the kernel itself, > so that all standard linux capture tools can then be used. > > /Bruce I felt like giving commets from my humble experiences,,, - In our case, KNI is always enabeld for each DPDK port, as it seemed handy that packet rx/tx stat and up/down status can be checked by ifconfig as well. Also, iface MIB become available as well via /sys/devices/pci.../net. As far as we checked it, it seemed that just creating KNI itself didn't much affect Dplane performance. (Just when we update statistics, there is a bit of overhead.) - I inserted rte_kni_tx_burst() call to packet RX path (after rte_eth_rx_burst) and TX path (after rte_eth_tx_burst, based on an assumption that just sent out pkt is not yet freed, it will be freed when the tx descriptor is overwritten by some time later tx packet.). The call to rte_kni_tx_burst() is enabled/disabled by some external capture enable/disable command. I copy the packet beforehand and pass the copied one to rte_kni_tx_burst(). In TX path, we might not need to copy if we just increment the packet refcnt by 1, but haven't yet tried such hack much. The packets sent to rte_kni_tx_burst() can then be captured by normal libpcap tools like tcpdump on the correspondent KNI. The performance loss when the capture was enabled was roughly 20-30%. (Perhaps it might change based on many factors.) By the way, in this way, we can enable tx-only or rx-only capture. - Some considerations, - Someone might not like capture on/off check everytime on normal fast path tx/rx route. I too, so created fastpath send routine and slowpath send routine, and switched the function pointer when the capture is enabled/disabled. But not sure if it was worth for the effort. - In this approach, everyone needs to create their own capture enable/disable command in their implementation, and it could be a bit bothering. I myself am not sure if it's possible, but if as in normal tcpdump, an invocation of tcpdump to a KNI interfce could be somehow notified to the correspondent DPDK port user application, and then the call to rte_kni_tx_burst() could be automatically enabled/disabled, that's cool. Thanks, Yoshinobu Inoue From: Bruce Richardson Subject: Re: [dpdk-dev] 2.3 Roadmap Date: Tue, 1 Dec 2015 10:03:33 +0000 > On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote: >> On Mon, 30 Nov 2015 22:53:50 +0000 >> Kyle Larose wrote: >> >> > Hi Tim, >> > >> > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim wrote: >> > >> > > Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve usability and debugging of DPDK applications. >> > >> > I'm curious about the proposed tcpdump support. Is there a concrete plan for this, or is that still being looked into? Sandvine is interested in contributing to this effort. Anything we can do to help? >> > >> > Thanks, >> > >> > Kyle >> >> We discussed an Ovscon doing a simple example of how to have a thread use named pipe >> support (already in tcpdump and wireshark). More complex solutions require changes to >> libpcap and application interaction. > > Our current thinking is to use kni to mirror packets into the kernel itself, > so that all standard linux capture tools can then be used. > > /Bruce >