MMC/SDIO stack under CAM

Thu Feb 11 18:47:27 UTC 2016

I'll use an excellent opportunity to post a small status update about my work :-)
* SDHC controller on Wandboard now works with the new stack;
* SDIO block read now works!
* camcontrol userland app is extended to support "mmcsdcmd" command that allows to send MMC commands from userland apps directly to the card via pass(4) device -- now we can write WLAN driver in userland :-D

On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" <johannes at brilliantservice.co.jp> wrote:
>Hi Ilya
>
>This is great!
>
>I've got a Tronsmart ARA X5 and just purchased a few UP
><http://up-shop.org/up-boards/2-up-board-2gb-16-gb-emmc-memory.html>
>boards
>and it would be really nice if I could utilize the onboard eMMC. These
>are
>all Intel Cherrytrail platforms.
>
>Please let me know if there's anything (testing?) I can do to speed up
>the
>process.
>
>
>
>--
>Name:     Johannes Lundberg
>Position: Mirama project leader
>Phone:    +1-408-636-2161
>Skype:    brilliantjohannes
>Online:   LinkedIn <http://jp.linkedin.com/in/lundbergjohannes>
>Facebook
><https://www.facebook.com/miramaone> Reddit
><https://www.reddit.com/user/yohanesu75/> Twitter
><https://twitter.com/Yohanesu75Tweet> GitHub
><https://github.com/yohanesu75>
>GitLab <https://gitlab.com/u/johannes_lundberg>
>Company:  Mirama <http://mira.ma> Brilliantservice US
><http://www.brilliantserviceusa.com> Brilliantservice JP
><http://www.brilliantservice.co.jp>
>
>On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin <ilya at bakulin.de> wrote:
>
>> 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
>>
>>
>>
>
>-- 
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
>もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
>複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
>---
>CONFIDENTIALITY NOTE: The information in this email is confidential
>and intended solely for the addressee.
>Disclosure, copying, distribution or any other action of use of this
>email by person other than intended recipient, is prohibited.
>If you are not the intended recipient and have received this email in
>error, please destroy the original message.

-- 
Простите за краткость, создано в K-9 Mail.