From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id A56F12EDA for ; Wed, 20 May 2015 10:32:08 +0200 (CEST) Received: by wgbgq6 with SMTP id gq6so44592032wgb.3 for ; Wed, 20 May 2015 01:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=lmEpCC/yXAIQc6ygYbaL/lkZzWmQtAlWqx9+gyWJ9hM=; b=OYbfjK/AAQYL1shIIcH30WvVEhGJN2K1w4a92HOCEhOuwQnRSZSzqmWXD8Ih3MlVA8 KtJhBHsPJ0LWbzHLlELitcuiVyd1Vx5AsU/JpBR9uhUoz5hRyaVSbYGlJKM/rCZPt1iy O7q5mMaBakS/BVHyJ24kDEEB3RklSABGpHck6h28Pf53VKheAGf/ikwZddL9gUsc9qJG S9TndakB4wkXlfmiEUIER0J55Dezcn+fvC0HmV16uNbC7XnbeMDyzDrJ1KxQb0g/1TMI JN4uZbJZPdUbySO5ZFZIa/LkHBXRUMO85ni2FFUKrbasPiuWpRlCweQZFnpFZgm56S2V Mg+g== X-Gm-Message-State: ALoCoQkekZunTSD5pO5ATQW/HEtP00JGovbs4GPfX2bOHZdyDi5AS7xMyIHkFVyt1DBVnSIZet6U X-Received: by 10.194.76.73 with SMTP id i9mr63524654wjw.149.1432110728176; Wed, 20 May 2015 01:32:08 -0700 (PDT) Received: from xps13.localnet ([62.159.77.186]) by mx.google.com with ESMTPSA id u6sm25568364wjy.13.2015.05.20.01.32.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 01:32:06 -0700 (PDT) From: Thomas Monjalon To: dev@dpdk.org, Bruce Richardson Date: Wed, 20 May 2015 10:31:22 +0200 Message-ID: <2340603.EB75GY9ZBE@xps13> Organization: 6WIND User-Agent: KMail/4.14.7 (Linux/4.0.1-1-ARCH; KDE/4.14.7; x86_64; ; ) In-Reply-To: <20150519113112.GA10700@bricha3-MOBL3> References: <1431361781-12621-1-git-send-email-bruce.richardson@intel.com> <20150519113112.GA10700@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCHv2 0/2] pktdev as wrapper type 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: Wed, 20 May 2015 08:32:09 -0000 2015-05-19 12:31, Bruce Richardson: > On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote: > > Hi all, > > > > after a small amount of offline discussion with Marc Sune, here is an > > alternative proposal for a higher-level interface - aka pktdev - to allow a > > common Rx/Tx API across device types handling mbufs [for now, ethdev, ring > > and KNI]. The key code is in the first patch fo the set - the second is an > > example of a trivial usecase. > > > > What is different about this to previously: > > * wrapper class, so no changes to any existing ring, ethdev implementations > > * use of function pointers for RX/TX with an API that maps to ethdev > > - this means there is little/no additional overhead for ethdev calls > > - inline special case for rings, to accelerate that. Since we are at a > > higher level, we can special case process some things if appropriate. This > > means the impact to ring ops is one (predictable) branch per burst > > * elimination of the queue abstraction. For the ring and KNI, there is no > > concept of queues, so we just wrap the functions directly (no need even for > > wrapper functions, the api's match so we can call directly). This also > > means: > > - adding in features per-queue, is far easier as we don't need to worry about > > having arrays of multiple queues. For example: > > - adding in buffering on TX (or RX) is easier since again we only have a > > single queue. > > * thread safety is made easier using a wrapper. For a MP ring, we can create > > multiple pktdevs around it, and each thread will then be able to use their > > own copy, with their own buffering etc. > > > > However, at this point, I'm just looking for general feedback on this as an > > approach. I think it's quite flexible - even more so than the earlier proposal > > we had. It's less proscriptive and doesn't make any demands on any other libs. > > > > Comments/thoughts welcome. > > Any comments on this RFC before I see about investing further time in it to clean > it up a bit and submit as a non-RFC patchset for merge in 2.1? I would say there are 2 possible approaches for KNI and ring handling: 1/ You Bruce, Marc and Keith are advocating for a layer on top of ethdev, ring, KNI and possibly other devices, which uses mbuf. The set of functions is simpler than ethdev but the data structure is mbuf which is related to ethdev layer. 2/ Konstantin and Neil talked about keeping mbuf for ethdev layer and related libs only. Ring and KNI could have an ethdev API with a reduced set of implemented functions. Crypto devices could adopt a specific crypto API and an ethdev API at the same time. I feel it's cleaner, more generic and more maintainable to have drivers implementing one or several stable APIs instead of having some restricted wrappers to update. Comments are welcome.