From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id BA38A370 for ; Tue, 1 Dec 2015 12:58:22 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 01 Dec 2015 03:58:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,368,1444719600"; d="scan'208";a="831759196" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.61]) by orsmga001.jf.intel.com with SMTP; 01 Dec 2015 03:58:18 -0800 Received: by (sSMTP sendmail emulation); Tue, 01 Dec 2015 11:58:16 +0025 Date: Tue, 1 Dec 2015 11:58:16 +0000 From: Bruce Richardson To: Yoshinobu Inoue Message-ID: <20151201115816.GA29824@bricha3-MOBL3> References: <20151130171655.70e4ce25@xeon-e3> <20151201100333.GA32252@bricha3-MOBL3> <20151201.202639.45956937.shin@lenovo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151201.202639.45956937.shin@lenovo> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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:58:23 -0000 On Tue, Dec 01, 2015 at 08:26:39PM +0900, Yoshinobu Inoue wrote: > 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 > Hi, that is indeed very similar to what we are thinking ourselves. Is there any of what you have already done that you could contribute publically to save us duplicating some of your effort? [The one big difference, is that we are not thinking of enabling kni permanently for each port, as the ethtool support is only present for a couple of NIC types, and solving that is a separate issue.:-)] /Bruce