Date: Sat, 01 Mar 2014 17:46:32 +0100 From: Ilya Bakulin <ilya@bakulin.de> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: MMC/SDIO stack under CAM Message-ID: <53120EE8.1080600@bakulin.de> In-Reply-To: <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Hi Adrian, On 24.02.14, 16:59, Adrian Chadd wrote: > hi, > > Let me just reiterate some .. well, experience doing this stuff at QCA. > > 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/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? > > 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 stack. 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), except 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... -- Regards, Ilya Bakulin [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMSDusACgkQo9vlj1oadwjzzQCeMSzl4e8wUqCK4s3kgBZpr1U8 JD8Anjz2mbLF4XVpGfCHDTIu5AlaKseg =JJfS -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53120EE8.1080600>