From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752202AbcFNMVZ (ORCPT ); Tue, 14 Jun 2016 08:21:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36077 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751202AbcFNMVU (ORCPT ); Tue, 14 Jun 2016 08:21:20 -0400 Date: Tue, 14 Jun 2016 14:21:13 +0200 From: Jesper Dangaard Brouer To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, Jason Wang , Eric Dumazet , davem@davemloft.net, netdev@vger.kernel.org, Steven Rostedt , kvm@vger.kernel.org, brouer@redhat.com Subject: Re: [PATCH v8 5/5] skb_array: resize support Message-ID: <20160614142113.1f0391d0@redhat.com> In-Reply-To: <20160613235450-mutt-send-email-mst@redhat.com> References: <1465851234-13558-1-git-send-email-mst@redhat.com> <20160613235450-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 14 Jun 2016 12:21:19 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 13 Jun 2016 23:54:50 +0300 "Michael S. Tsirkin" wrote: > Update skb_array after ptr_ring API changes. > > Signed-off-by: Michael S. Tsirkin Acked-by: Jesper Dangaard Brouer Tested-by: Jesper Dangaard Brouer Also did resize unit test: https://github.com/netoptimizer/prototype-kernel/commit/af0b4d7e7261e9 The parallel benchmark: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_parallel01.c Have been adjusted to use the non-BH variant of the lock. And the parallel benchmark results, where a single producer and a single consumer CPU runs concurrently, and the queue always partly full (optimal case for minimize cache-contention): On CPU i7-4790K @ 4.00GHz: - Enqueue 32 cycles(tsc) 8.162 ns - Dequeue 33 cycles(tsc) 8.417 ns Notice this is an extremely good concurrency results, as it is very close to the optimal case benchmark 26 cycles, when running enqueue+dequeue on the same CPU in a tight loop[2]. -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer [2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/lib/skb_array_bench01.c