From owner-freebsd-arm@freebsd.org Sun Jan 3 09:55:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 580C4A6018A; Sun, 3 Jan 2016 09:55:58 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 08BE51A28; Sun, 3 Jan 2016 09:55:57 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com DBCC14E76D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1451814955; bh=4nY1rmF6ktwUoLOILKZ5CojkbAO06M52FQHmtyIJKDE=; h=Subject:References:Cc:To:From:Date:In-Reply-To; b=eEJYuw7UpRFFgM+2I0Z71x762hUfC+2BO6x8sNtQHGe1la/1OOzN4/Bb3EFxFPWq5 cjrZ3lKHXVPRhFB6KGlhl3vroR858cPDh6+DuoGREE1s9SquZdUjPPD62XXmHouCyH 4lPrr6LUF0kUjqk13difA9Qg2clMkQxEiOQB7HlY= 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> <53120EE8.1080600@bakulin.de> Cc: Adrian Chadd , Alexander Motin , "freebsd-arm@freebsd.org" , Warner Losh To: "freebsd-hackers@freebsd.org" From: Ilya Bakulin X-Enigmail-Draft-Status: N1110 Message-ID: <5688F015.4090002@bakulin.de> Date: Sun, 3 Jan 2016 10:55:33 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdKPQb5BR1laisQxTkM8FwTwAWJqK4t22" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 09:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sdKPQb5BR1laisQxTkM8FwTwAWJqK4t22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So, more than one year has passed, and I'd like to resurrect this work and move forward. I have uploaded a new diff and created a completely new revision to track the development: https://reviews.freebsd.org/D4761 What it is able to do now: * Read/write on SD/SDHC/MMC cards! * Detect SDIO cards and create devices that correspond to SDIO functions This all works only on BeagleBone currently, because some changes need to be done in each SDHCI-compliant driver to make it interact with CAM. I have purchased a Wandboard Quad that has an integrated SDIO WiFi chip, so I hope to tweak its SDHCI driver as well. I haven't profiled the stack because: * Now we have only SD/MMC cards that are slow anyway; * I don't know how to do it in FreeBSD :-) Please review this diff and tell what you think! On 01/03/14 18:05, Adrian Chadd wrote: > On 1 March 2014 08:46, Ilya Bakulin wrote: >> Hi Adrian, >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >>> hi, >>> >>> Let me just reiterate some .. well, experience doing this stuff at QC= A. >>> >>> You really, absolutely don't want too much overhead in the MMC/SDIO >>> path between whatever is issuing things and the network driver. >>> >>> There was significant performance work done at QCA on a local MMC/SDI= O >>> 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? > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at small > transactions to sustain the wifi speeds customers required. > >>> 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 loca= l >>> 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 massiv= e >>> 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 th= an >> 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 prett= y >> obvious, but then these cards will be likely the bottleneck, not the s= tack. >> And the only goal would be to not make the stack slower than it is now= =2E >> But, as ATA devices are much faster than MMC/SD, I don't think this wi= ll >> be a problem. >> >> For SDIO things are different. But we don't have any drivers (yet), ex= cept >> 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... > That sounds like a plan. > > Just note that although storage looks like it's doing much more > throughput, the IO size also matters. As I said above, it's not > uncommon to have > 1000 receive frames a second on 802.11n; and that > can peak much higher than that. That's not the kind of IO rate you see > on SD cards. :-) > > > > -a > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" > --=20 Regards, Ilya Bakulin --sdKPQb5BR1laisQxTkM8FwTwAWJqK4t22 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 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlaI8BsACgkQo9vlj1oadwjUfACguMrOckb94Xll9QDLznZg3WAJ BS4AoPJnEHpH3gg/0+voWbDOQ017IHs+ =gbnk -----END PGP SIGNATURE----- --sdKPQb5BR1laisQxTkM8FwTwAWJqK4t22--