From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id CC0631094 for ; Tue, 17 Jan 2017 18:57:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 17 Jan 2017 09:57:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,245,1477983600"; d="scan'208";a="810003425" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.38]) ([10.237.220.38]) by FMSMGA003.fm.intel.com with ESMTP; 17 Jan 2017 09:57:04 -0800 To: Shirley Avishour References: <900f05e3-f251-2526-de4a-4c1e3ca5d713@intel.com> Cc: dev@dpdk.org From: Ferruh Yigit Message-ID: Date: Tue, 17 Jan 2017 17:57:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <900f05e3-f251-2526-de4a-4c1e3ca5d713@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] drops while transmitting to the kni using rte_kni_tx_burst() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 17:57:07 -0000 On 1/17/2017 5:46 PM, Ferruh Yigit wrote: > On 1/16/2017 2:58 PM, Shirley Avishour wrote: >> I am currently using the kernel interface for recording the received >> traffic by duplicating the received packets and sending a copy to the >> kni (and performing pcap_open_live on the kni). >> my goal rate is around 500Mbps. is it possible to achieve it via the kni ?? > > According quick experiment, > - with kni module lo_mode_fifo_skb (which send all received packets to > tx, but allocating and copying data to skb to be more realistic) > - single kernel thread > - kernel thread bind to a core > - using kni sample app > - With small packets > > Best numbers get when rx,tx and kernel cores are in same socket with the > NIC, it is ~1.7Mpps (million packet per second) > > When KNI_RX_LOOP_NUM increased to 10000, it becomes ~1.9Mpps. > And again, very quick test, between two KNI ports, with kni sample app, using iperf default values, gives ~3 Gbits/sec >> >> >> On Mon, Jan 16, 2017 at 4:55 PM, Ferruh Yigit > > wrote: >> >> On 1/16/2017 2:47 PM, Shirley Avishour wrote: >> > Hi, >> > As I wrote the kernel thread runs on a dedicated lcore. >> > running top while my application is running I see kni_single and the cpu >> > usage is really low... >> > Is there any rate limitation for transmitting to the kernel interface >> > (since packets are being copied in the kernel). >> >> Yes, kind of, kernel thread sleeps periodically, with a value defined by >> KNI_KTHREAD_RESCHEDULE_INTERVAL. You can try tweaking this value, if you >> want thread do more work, less sleep J >> >> Also KNI_RX_LOOP_NUM can be updated for same purpose. >> >> > >> > >> > On Mon, Jan 16, 2017 at 4:42 PM, Ferruh Yigit >> > >> >> wrote: >> > >> > On 1/16/2017 12:20 PM, Shirley Avishour wrote: >> > > Hi, >> > > I have an application over dpdk which is consisted of the >> following threads >> > > each running on a separate core: >> > > 1) rx thread which listens on in a poll mode for traffic >> > > 2) 2 packet processing threads (for load balancing) >> > > 3) kni thread (which also runs on a separate core). >> > >> > This is kernel thread, right? Is it bind to any specific core? >> > Is it possible that this thread shares the core with 2nd >> processing >> > thread when enabled? >> > >> > > >> > > the rx thread receives packets and clones them and transmit >> a copy >> > to the >> > > kni and the other packet is sent to the packet processing unit >> > (hashing >> > > over 2 threads). >> > > the receive traffic rate is 100Mbps. >> > > When working with single packet processing thread I am able >> to get >> > all the >> > > 100Mbps towards the kni with no drops. >> > > but when I activate my application with 2 packet processing >> > threads I start >> > > facing drops towards the kni. >> > > the way I see it the only difference now is that I have another >> > threads >> > > which handles an mbuf and frees it once processing is completed. >> > > Can anyone assist with this case please? >> > > >> > > Thanks! >> > > >> > >> > >> >> >