Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757645AbbLBI03 (ORCPT ); Wed, 2 Dec 2015 03:26:29 -0500 Received: from mail-oi0-f54.google.com ([209.85.218.54]:36720 "EHLO mail-oi0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932327AbbLBI0Y (ORCPT ); Wed, 2 Dec 2015 03:26:24 -0500 MIME-Version: 1.0 In-Reply-To: <20151130.112500.293198684175670933.davem@redhat.com> References: <20151129.210210.1777978635596463961.davem@davemloft.net> <20151130.112500.293198684175670933.davem@redhat.com> Date: Wed, 2 Dec 2015 09:26:23 +0100 Message-ID: Subject: Re: [PATCH 00/13] mvneta Buffer Management and enhancements From: Marcin Wojtas To: Florian Fainelli Cc: David Miller , linux-kernel@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , netdev@vger.kernel.org, Thomas Petazzoni , Andrew Lunn , Russell King - ARM Linux , Jason Cooper , Yair Mahalalel , Grzegorz Jaszczyk , Simon Guinot , Evan Wang , nadavh@marvell.com, Lior Amsalem , Tomasz Nowicki , =?UTF-8?Q?Gregory_Cl=C3=A9ment?= , nitroshift@yahoo.com, Sebastian Hesselbarth Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1397 Lines: 34 Hi Florian, Can you please describe in more details, what would you expect from such special abstraction layer regarding buffer managers? I'd like to understand more of your expectations and evaluate possible work. Best regards, Marcin 2015-11-30 17:25 GMT+01:00 David Miller : > From: Marcin Wojtas > Date: Mon, 30 Nov 2015 15:13:22 +0100 > >> What kind of abstraction and helpers do you mean? Some kind of API >> (e.g. bm_alloc_buffer, bm_initialize_ring bm_put_buffer, >> bm_get_buffer), which would be used by platform drivers (and specific >> aplications if one wants to develop on top of the kernel)? >> >> In general, what is your top-view of such solution and its cooperation >> with the drivers? > > The tricky parts involved have to do with allocating pages for the > buffer pools and minimizing the number of atomic refcounting > operations on those pages for for the puts and gets, particularly > around buffer replenish runs. > > For example, if you're allocating a page for a buffer pool the device > will chop into N (for any N < PAGE_SIZE) byte pieces, you can > eliminate many atomic operations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/