From owner-freebsd-arm@FreeBSD.ORG Sat Mar 1 16:46:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79645D0F; Sat, 1 Mar 2014 16:46:40 +0000 (UTC) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 06DA7197F; Sat, 1 Mar 2014 16:46:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 olymp.kibab.com 79A1F3F447 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1393692398; bh=d+8GHcINLy78fyewYr4+BaecZQM39xZyj6/tH5aoXfs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=gP/mFgu2B0Dtddl6tkVvXgg3cDBDp3K8L7xPeD4wzXRmGFNmKD8jg98LfIjEWn0Bk isPtKWOkPic3MDZPCoYm7LyH23TG8ec/kNYEd7gDsGsfZscvauTR5Z4Y65R12FIYkx OicOG/i3ATEifhR0AvXj/k3vdu9ZeX1Gb5hBcVPs= Message-ID: <53120EE8.1080600@bakulin.de> Date: Sat, 01 Mar 2014 17:46:32 +0100 From: Ilya Bakulin MIME-Version: 1.0 To: Adrian Chadd Subject: Re: MMC/SDIO stack under CAM References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE" Cc: "freebsd-hackers@freebsd.org" , Alexander Motin , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 16:46:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian, On 24.02.14, 16:59, Adrian Chadd wrote: > hi, >=20 > Let me just reiterate some .. well, experience doing this stuff at QCA.= >=20 > You really, absolutely don't want too much overhead in the MMC/SDIO > path between whatever is issuing things and the network driver. >=20 > There was significant performance work done at QCA on a local MMC/SDIO > driver and bus to get extremely low latency and CPU utilisation when > pushing around small transactions. The current CAM locking model is > not geared towards getting to high transaction rates. So here you mean some work done on Linux MMC/SDIO stack by QCA which made it far better than current Linux MMC stack in terms of high SDIO I/O rates? >=20 > You may think this is a very architecturally pretty solution and it > indeed may be. But if it doesn't perform as well as the existing local > hacks that vendors have done, no company deploying this hardware is > going to want to use it. They'll end up realising there's this massive > CAM storage layer in between and either have to sit down to rip it up > and replace it with something lightweight, or they'll say "screw it" > and go back to the vendor supplied hacked up Linux solution. I think that if the "architecturally pretty solution" behaves worse than some ugly hacks, then it may be not so pretty or the architecture is just broken by design. > So I highly recommend you profile things - and profile things with > lots of small transactions. If the CAM overhead is more than a tiny, > tiny fraction of CPU at 25,000 pps, your solution won't scale. :-) I don't really know what to compare with. For MMC/SD cards it is pretty obvious, but then these cards will be likely the bottleneck, not the stac= k. And the only goal would be to not make the stack slower than it is now. But, as ATA devices are much faster than MMC/SD, I don't think this will be a problem. For SDIO things are different. But we don't have any drivers (yet), excep= t mv_sdiowl that I'm writing, to test on. So I have to bring the SDIO stack on CAM, than bring mv_sdiowl to the state when it can actually transmit the data, and then compare performance with the vendor-supplied Linux driver. We'll see then if there is a room for improvement... --=20 Regards, Ilya Bakulin --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMSDusACgkQo9vlj1oadwjzzQCeMSzl4e8wUqCK4s3kgBZpr1U8 JD8Anjz2mbLF4XVpGfCHDTIu5AlaKseg =JJfS -----END PGP SIGNATURE----- --IRvQfdUsQjJjJ6fSiATBTXIHeO5t1kqLE--