From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: libata+SGIO: is .dma_boundary respected? Date: Tue, 21 Mar 2006 14:29:34 -0500 Message-ID: <4420541E.3070303@pobox.com> References: <441DC397.9040504@rtr.ca> <441DC9CB.7030203@pobox.com> <441DCAC9.5090603@rtr.ca> <441DCF73.2080600@pobox.com> <441DD101.5050202@rtr.ca> <441DD300.9050702@rtr.ca> <441F544A.6080301@pobox.com> <441F8478.50806@rtr.ca> <441F99AC.4000200@pobox.com> <442006BC.8020100@rtr.ca> <20060321184215.GJ4285@suse.de> <442051A0.1050200@rtr.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:26028 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S932429AbWCUT3j (ORCPT ); Tue, 21 Mar 2006 14:29:39 -0500 In-Reply-To: <442051A0.1050200@rtr.ca> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Mark Lord Cc: Jens Axboe , IDE/ATA development list , James Bottomley , Benjamin Herrenschmidt Mark Lord wrote: > Jens Axboe wrote: > .. > >> Seems to me that your reasoning is correct. It's a fact that the >> original block mapped sg lists satisfies all requirements of the device >> driver and/or hardware, otherwise would be a bug. The iommu may go nuts >> of course, but logically that new sg list should be choppable into the >> same requirements. > > > I just finished going through all of the arch implementations and, > as near as I can tell, they only ever *merge* sg list items, > and never create additional sg entries. > > So low-level drivers (at present) can safely report their real limits, > and then in their fill_sg() routines they can run around and split up > any IOMMU merges that their hardware cannot tolerate. I remain highly skeptical, and would be interested to see James and Ben weight in on the subject, as they were the key iommu vmerge people around the time libata ata_fill_sg() was originally written (and fixed by BenH). >> It would be much nicer if the iommu actually had some more knowledge, >> ideally the same requirements that the block layer is faced with. No >> driver should have to check the mapped sg list. > Yup. Absolutely. So long as they continue to never *add* new sg entries > (only doing merges instead), then I believe they just need to know the > device's .dma_boundary parameter. We could pass this to them as an extra > parameters, or perhaps embed it into the sg_list data structure somehow. > > In the case of sata_mv on the Marvell 6081 (which I'm looking at this week) > it's hardware limit is actually 0xffffffff rather than 0xffff. If the limit is not 0xffff, then there's no need for any of this limitation junk. No s/g entry splitting after pci_map_sg(), no artificial sg_tablesize limitation, etc. > I wonder how well Linux drivers in general deal with that on a 64-bit > machine? Works just fine. Jeff