From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 7C54168AF for ; Sat, 15 Nov 2014 00:54:45 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 14 Nov 2014 16:04:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,388,1413270000"; d="scan'208";a="608160187" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by orsmga001.jf.intel.com with ESMTP; 14 Nov 2014 16:04:47 -0800 Received: from pgsmsx106.gar.corp.intel.com (10.221.44.98) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 15 Nov 2014 08:04:47 +0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 15 Nov 2014 08:04:46 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 08:04:45 +0800 From: "Zhou, Danny" To: "Sanford, Robert" , Thomas Monjalon , "dev@dpdk.org" Thread-Topic: Enhance KNI DPDK-app-side to be Multi-Producer/Consumer Thread-Index: AdAATsFuOFSVQkZQSEOfgayUigXcoQAGA4TQ Date: Sat, 15 Nov 2014 00:04:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Enhance KNI DPDK-app-side to be Multi-Producer/Consumer 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: Fri, 14 Nov 2014 23:54:46 -0000 It will be always good if you can submit the RFC patch in terms of KNI opti= mization. On the other hand, do you have any perf. data to prove that your patchset c= ould improve KNI performance which is the concern that most customers care about? We int= roduced multiple-threaded KNI kernel support last year, if I remember correctly, th= e key perform bottle-neck we found is the skb alloc/free and memcpy between skb and mbuf.= Would be=20 very happy if your patchset can approve I am wrong. > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sanford, Robert > Sent: Saturday, November 15, 2014 5:06 AM > To: Thomas Monjalon; dev@dpdk.org > Subject: [dpdk-dev] Enhance KNI DPDK-app-side to be Multi-Producer/Consum= er >=20 > Hello Thomas, >=20 > I want to discuss a small enhancement to KNI that we developed. We wanted > to send/receive mbufs between one KNI device and multiple cores, but we > wanted to keep the changes simple. So, here were our requirements: >=20 > 1. Don't use heavy synchronization when reading/writing the FIFOs in > shared memory. > 2. Don't make any one core (data or control plane) perform too much work > shuffling mbufs to/from the FIFOs. > 3. Don't use an intermediate RTE ring to drop off mbufs when another core > is already accessing the same KNI FIFO. > 4. Since (for our private use case) we don't need MP/MC on the kernel > side, don't change the kernel KNI code at all. > 5. Don't change the request/reply logic. It stays single-threaded on both > sides. >=20 > Here is what we came up with: >=20 > 1. Borrow heavily from the librte_ring implementation. > 2. In librte_kni structure rte_kni, supplement each rte_kni_fifo (tx, rx, > alloc, and free q) with another private, corresponding structure that > contains a head, tail, mask, and size field. > 3. Create kni_fifo_put_mp function with merged logic of kni_fifo_put and > __rte_ring_mp_do_enqueue. After we update the tail index (which is privat= e > to the DPDK-app), we update the FIFO write index (shared between app and > kernel). > 4. Create kni_fifo_get_mc function with merged logic of kni_fifo_get and > __rte_ring_mc_do_dequeue. After we update the tail index, update the FIFO > read index. > 5. In rte_kni_tx_burst and kni_alloc_mbufs, call kni_fifo_put_mp instead > of kni_fifo_put. > 6. In rte_kni_rx_burst and kni_free_bufs, call kni_fifo_get_mc instead of > kni_fifo_get. >=20 > We believe this is a common use case, and thus would like to contribute i= t > to dpdk.org. > Questions/comments: > 1. Are you interested for us to send the changes as an RFC? > 2. Do you agree with this approach, or would it be better, say, to rewrit= e > both sides of the interface to be more like librte_ring? > 3. Perhaps we could improve upon kni_allocate_mbufs, as it blindly > attempts to allocate and enqueue a constant number of mbufs. We have not > really focused on the kernel =3D=3D> app data path, because we were only > interested in app =3D=3D> kernel. >=20 > -- > Regards, > Robert Sanford