From owner-freebsd-arch@FreeBSD.ORG Sat Sep 29 16:20:50 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA6B16A419 for ; Sat, 29 Sep 2007 16:20:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 60B2713C45D for ; Sat, 29 Sep 2007 16:20:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [192.168.254.15] (ydesk.samsco.home [192.168.254.15]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8TGKfhN084918; Sat, 29 Sep 2007 10:20:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46FE7B59.7080003@samsco.org> Date: Sat, 29 Sep 2007 10:20:41 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans Petter Selasky References: <200709262157.02712.hselasky@c2i.net> <200709281753.30367.hselasky@c2i.net> <20070928.141345.78789158.imp@bsdimp.com> <200709291309.05747.hselasky@c2i.net> In-Reply-To: <200709291309.05747.hselasky@c2i.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [192.168.254.1]); Sat, 29 Sep 2007 10:20:42 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-arch@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2007 16:20:50 -0000 Hans Petter Selasky wrote: > On Friday 28 September 2007, Warner Losh wrote: > >>Hans Petter Selasky wrote: >> >>>>Well, the point is that I'm not sure why you're so worried about >>>>performance issues with USB and busdma. Do you have any test data that >>>>shows that it's a problem? >>> >>>It is a problem on embedded devices. Typically not for an ordinary PC >>>user. >> >>I'm curious. What's the problem? > > > Technically, if you load a buffer pointer and length that is not cache aligned > nor host aligned then you should bounce all the data no matter what. If you > do not bounce under those conditions you might get trouble. > > struct my_softc { > uint8_t hdr[2]; > uint8_t eth_pkt[1500]; > uint8_t other_important_stuff[546]; > } __aligned(PAGE_SIZE); > > Can "eth_pkt" be loaded into DMA ? No, it has an offset of 2. > > struct my_softc { > uint8_t eth_pkt[1500]; > uint8_t other_important_stuff[548]; > } __aligned(PAGE_SIZE); > > Can "eth_pkt" be loaded into DMA ? No, "other_important_stuff" might get lost > when the cache is invalidated. > > struct my_softc { > uint8_t eth_pkt[1500]; > } __aligned(PAGE_SIZE); > > Can "eth_pkt" be loaded into DMA ? Yes, I see no problem. > > Is it guaranteed that the "m_data" field of a mbuf will always be correctly > aligned for the CPU/DMA cache in addition to the host alignment ? > As Warner said, a lot of this is dependent on the device hardware, not the CPU, and it's a problem that is already well understood and addressed in those areas in FreeBSD. > Does bus_dma support bouncing using multiple pages instead of using one > contiguous segment ? Yes, busdma bounces on a page-by-page basis. In fact, when doing re-alignments, it'll attempt to bounce only the begining segment instead of the entire buffer. > > Please correct me if I am wrong. busdma is something that is both woefully underdocumented and much more powerful and featureful than is what is available in most other OS's, so please feel free to ask more questions like these. Scott