From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755549Ab3BDVzF (ORCPT ); Mon, 4 Feb 2013 16:55:05 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:40803 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755076Ab3BDVzD (ORCPT ); Mon, 4 Feb 2013 16:55:03 -0500 Message-ID: <51102E25.8040107@ti.com> Date: Mon, 4 Feb 2013 16:54:45 -0500 From: Cyril Chemparathy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Linus Walleij CC: Mark Brown , , Sergei Shtylyov , Linux Documentation List , Lindgren , Russell King - ARM Linux , Vinod Koul , "Nair, Sandeep" , Chris Ball , Matt Porter , Arnd Bergmann , Devicetree Discuss , Rob Herring , Linux OMAP List , ARM Kernel List , Linux DaVinci Kernel List , "Cousson, Benoit" , Linux MMC List , Linux Kernel Mailing List , Landley , Dan Williams , Linux SPI Devel List Subject: Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common References: <510C2A47.1090607@mvista.com> <20130201205600.GA31762@arwen.pp.htv.fi> <20130201213003.GW2637@n2100.arm.linux.org.uk> <20130204154153.GA18237@arwen.pp.htv.fi> <510FF1A6.403@mvista.com> <20130204164712.GB4269@arwen.pp.htv.fi> <510FF5C9.3030600@mvista.com> <20130204170216.GC4269@arwen.pp.htv.fi> <51100A72.6030909@ti.com> <20130204203358.GX4720@opensource.wolfsonmicro.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/04/2013 04:11 PM, Linus Walleij wrote: > On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown > wrote: >> On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote: >>> On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote: >> >>>> Based on our experience with fitting multiple subsystems on top of this >>>> DMA-Engine driver, I must say that the DMA-Engine interface has proven >>>> to be a less than ideal fit for the network driver use case. >> >>>> The first problem is that the DMA-Engine interface expects to "push" >>>> completed traffic up into the upper layer as a part of its callback. >>>> This doesn't fit cleanly with NAPI, which expects to "pull" completed >>>> traffic from below in the NAPI poll. We've somehow kludged together a >>>> solution around this, but it isn't very elegant. >> >>> I cannot understand the actual technical problem from the above >>> paragraphs though. dmaengine doesn't have a concept of pushing >>> nor polling, it basically copies streams of words from A to B, where >>> A/B can be a device or a buffer, nothing else. >> >>> The thing you're looking for sounds more like an adapter on top >>> of dmaengine, which can surely be constructed, some >>> drivers/dma/dmaengine-napi.c or whatever. >> >> Broadly speaking what NAPI wants is to never get any callbacks from the >> hardware (or DMAs). It wants to wake up periodically, take a look at >> what packets have been read by the hardware and process them. The goal >> is to have the DMAs sitting and running without disturbing the processor >> at all after the first packet has been handled. > > OK we should definately be able to encompass that in dmaengine > quite easily. > > So I think the above concerns are moot. The callback we can > set on cookies is entirely optional, and it's even implemented by > each DMA engine, and some may not even support it but *require* > polling, and then it won't even be implemented by the driver. > > Which probably stems from the original design of the dmaengine > API, which was for TCP networking acceleration, mainly. > > Cyril, just stack up the cookies and take a sweep over them to see > which ones are baked when the NAPI poll comes in -> problem > solved. > You're assuming that cookies complete in order. That is not necessarily true. Thanks -- Cyril.