Date: Sun, 3 Jan 2016 10:55:33 +0100 From: Ilya Bakulin <ilya@bakulin.de> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Cc: Adrian Chadd <adrian.chadd@gmail.com>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: MMC/SDIO stack under CAM Message-ID: <5688F015.4090002@bakulin.de> In-Reply-To: <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@mail.gmail.com> <53120EE8.1080600@bakulin.de> <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ilya@bakulin.de> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5688F015.4090002>