MMC/SDIO stack under CAM

[Ilya Bakulin]

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 at 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 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?
> 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 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...
> 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>


-- 
Regards,
Ilya Bakulin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160103/a8746731/attachment.sig>