From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 53D4A91 for ; Sat, 10 Nov 2018 07:17:38 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 22:17:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,486,1534834800"; d="scan'208";a="279933557" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga006.fm.intel.com with ESMTP; 09 Nov 2018 22:17:36 -0800 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.70]) by FMSMSX108.amr.corp.intel.com ([169.254.9.157]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 22:17:36 -0800 From: "Wiles, Keith" To: Harsh Patel CC: "users@dpdk.org" Thread-Topic: [dpdk-users] Query on handling packets Thread-Index: AQHUdzydRRkBFdv4fkKjO7j2RJcyb6VGGaEAgACGp4CAAAyagIABE0+AgAFRlQA= Date: Sat, 10 Nov 2018 06:17:35 +0000 Message-ID: <3C60E59D-36AD-4382-8CC3-89D4EEB0140D@intel.com> References: <71CBA720-633D-4CFE-805C-606DAAEDD356@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.189.133] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-users] Query on handling packets X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 06:17:39 -0000 Please make sure to send your emails in plain text format. The Mac mail pro= gram loves to use rich-text format is the original email use it and I have = told it not only send plain text :-( > On Nov 9, 2018, at 4:09 AM, Harsh Patel wrote: >=20 > We have implemented the logic for Tx/Rx as you suggested. We compared the= obtained throughput with another version of same application that uses Lin= ux raw sockets.=20 > Unfortunately, the throughput we receive in our DPDK application is less = by a good margin. Is this any way we can optimize our implementation or any= thing that we are missing? >=20 The PoC code I was developing for DAPI I did not have any performance of is= sues it run just as fast with my limited testing. I converted the l3fwd cod= e and I saw 10G 64byte wire rate as I remember using pktgen to generate the= traffic. Not sure why you would see a big performance drop, but I do not know your a= pplication or code. > Thanks and regards > Harsh & Hrishikesh >=20 > On Thu, 8 Nov 2018 at 23:14, Wiles, Keith wrote: >=20 >=20 >> On Nov 8, 2018, at 4:58 PM, Harsh Patel wrote= : >>=20 >> Thanks >> for your insight on the topic. Transmission is working with the functio= ns you mentioned. We tried to search for some similar functions for handlin= g incoming packets but could not find anything. Can you help us on that as = well? >>=20 >=20 > I do not know if a DPDK API set for RX side. But in the DAPI (DPDK API) P= oC I was working on and presented at the DPDK Summit last Sept. In the PoC = I did create a RX side version. The issues it has a bit of tangled up in th= e DAPI PoC. >=20 > The basic concept is a call to RX a single packet does a rx_burst of N nu= mber of packets keeping then in a mbuf list. The code would spin waiting fo= r mbufs to arrive or return quickly if a flag was set. When it did find RX = mbufs it would just return the single mbuf and keep the list of mbufs for l= ater requests until the list is empty then do another rx_burst call. >=20 > Sorry this is a really quick note on how it works. If you need more detai= ls we can talk more later. >>=20 >> Regards, >> Harsh >> and Hrishikesh. >>=20 >>=20 >> On Thu, 8 Nov 2018 at 14:26, Wiles, Keith wrote: >>=20 >>=20 >> > On Nov 8, 2018, at 8:24 AM, Harsh Patel wro= te: >> >=20 >> > Hi, >> > We are working on a project where we are trying to integrate DPDK with >> > another software. We are able to obtain packets from the other environ= ment >> > to DPDK environment in one-by-one fashion. On the other hand DPDK allo= ws to >> > send/receive burst of data packets. We want to know if there is any >> > functionality in DPDK to achieve this conversion of single incoming pa= cket >> > to a burst of packets sent on NIC and similarly, conversion of burst r= ead >> > packets from NIC to send it to other environment sequentially? >>=20 >>=20 >> Search in the docs or lib/librte_ethdev directory on rte_eth_tx_buffer_i= nit, rte_eth_tx_buffer, ... >>=20 >>=20 >>=20 >> > Thanks and regards >> > Harsh Patel, Hrishikesh Hiraskar >> > NITK Surathkal >>=20 >> Regards, >> Keith >>=20 >=20 > Regards, > Keith >=20 Regards, Keith