From owner-freebsd-arch@FreeBSD.ORG Tue Jun 17 04:53:30 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E97C337B401 for ; Tue, 17 Jun 2003 04:53:30 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8310143FB1 for ; Tue, 17 Jun 2003 04:53:30 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 6714B2ED442; Tue, 17 Jun 2003 04:53:30 -0700 (PDT) Date: Tue, 17 Jun 2003 13:53:30 +0200 From: Maxime Henrion To: Harti Brandt Message-ID: <20030617115330.GS21011@elvis.mu.org> References: <20030617124004.Y77677@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030617124004.Y77677@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: busdma sync problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2003 11:53:31 -0000 Harti Brandt wrote: > > Hi, > > I have drivers for several cards that use shared host memory for > communication between the card and the driver. In most cases these memory > areas are used for queues: the driver writes on one end, the card reads on > the other or the other way around. The problem is, that with the current > bus_dma_sync call there is no way to correctly synchronize these queues, > because bus_dma_sync synchonizes always the complete map. NetBSD > bus_dma_sync has two additional parameters for that case: an offset and > a length describing the part of the map to synchronize. Unless I got the > above entirely wrong, I suppose we also need this functionality. Indeed. This can also be used to slightly improve performance with PAE kernels because PAE causes lots of bounce buffers to be used, and with an offset and length parameter, we can reduce the number of bytes that will be copied on bus_dmamap_sync(). I'm not sure the performance difference would be measurable though. I'm getting a bit off topic there, but for what it's worth, a way to greatly improve network performance with PAE kernels would be to teach the mbuf allocator how to try to allocate mbufs in memory where no bounce buffers are required. > The question is how to introduce it. The easy way is to implement a new > function, say bus_dma_sync_size with the same signature as the NetBSD one. > The formally more correct way would be to just change our function and all > its callers. This would, of course, break the interface and I suppose it's > too late for 5.X. > > So should I go the first way? Is there anybody who would be willing to > look at the patch? I don't really like how the NetBSD interface forces us to always specify the length and offset, even though in most cases we want to sync the whole map. However, I believe it would be more beneficial at this point in time to try to make our busdma API as close as NetBSD's one as possible. I bet we'll end up using more macros, as the NetBSD folks do in their drivers, to circumvent the fact that it's annoying to always have to specify the length and offset to bus_dmamap_sync(). When you have this done, I'll be happy to take a look at it if you want me to. Cheers, Maxime