Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Dec 2012 17:54:07 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin <jhb@freebsd.org>, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org
Subject:   Re: Call for testing and review, busdma changes
Message-ID:  <E89ED853-3CCC-4F16-8333-89D8060D95F4@bsdimp.com>
In-Reply-To: <alpine.BSF.2.00.1212090840080.4081@desktop>
References:  <alpine.BSF.2.00.1212080841370.4081@desktop> <1355077061.87661.320.camel@revolution.hippie.lan> <alpine.BSF.2.00.1212090840080.4081@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
[[ looks like Ian answered the other questions ]]


On Dec 9, 2012, at 11:48 AM, Jeff Roberson wrote:
>>> The next step is to allow for dma loading of physical addresses.  =
This
>>> will permit unmapped I/O.  Which is a significant performance =
optimization
>>> targeted for 10.0.
>>=20
>> This sounds scary for arm and mips, or more specifically for VIVT =
cache
>> platforms that can only do a sync based on virtual addresses.  Can =
you
>> talk some more about the plans for this?
>=20
> It will be for addresses which were never mapped into kva.  To support =
unmaapped io.  There will only be a need for bounce pages, no syncing.

If there's a virtual mapping at all for the page (not just a kva), then =
we need to flush/invalidate cache for those pages for safety unless we =
know for sure there's nothing in the cache.  It these are pages that =
have never been mapped (say for zero copy between storage and network =
controllers), then there won't be a problem. The whole reason for cache =
jockeying is to make sure that any pending writes to the data are =
flushed, and that any cached notion of the pages are invalidated once =
the read is done.  This is more important for mbuf operations, =
operations with the USB stack or anything else that marshals data it =
generates to be consumed by the stack/hardware.

Warner




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E89ED853-3CCC-4F16-8333-89D8060D95F4>