Date: Fri, 12 Feb 2016 22:48:52 -0800 From: Russell Haley <russ.haley@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Ilya Bakulin <ilya@bakulin.de>, "Lundberg, Johannes" <johannes@brilliantservice.co.jp>, "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: <CABx9NuRTB1L=APP=MrzvCWUGxw9=YJLoo7Nx_sJpavXJzoxfVA@mail.gmail.com> In-Reply-To: <CAJ-Vmok_SWXR-Kh%2BFsp303w8NVP7sP-mzbbGphopUyfawff3gg@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> <5688F015.4090002@bakulin.de> <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg%2Bs2DACebopA@mail.gmail.com> <DD0089CC-19BF-4179-9A05-6B920B1DF7F9@bakulin.de> <20160213035806.4403283.12124.2928@gmail.com> <CAJ-Vmok_SWXR-Kh%2BFsp303w8NVP7sP-mzbbGphopUyfawff3gg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 12, 2016 at 8:16 PM, Adrian Chadd <adrian.chadd@gmail.com> wrot= e: > On 12 February 2016 at 19:58, Russell Haley <russ.haley@gmail.com> wrote: >> Hi Ilya, so does that mean I can take a linux driver for an SDIO wifi ca= rd and build it using a reference to your library and everything should "ju= st work"? > > nope. there's a lot more to it than that. But it's a good start - > getting the driver up and doing IO to the card is a big step. > > > > -a > Okay, thanks. But if I include his CAM driver and then use the patch below for IMX6 on my Hummingboard, I would be able to test the driver? Will a simple kldstat be enough to verify I am using his driver or is there something more direct in dtrace? Thanks, Russ >> Thanks, >> Russ >> >> Sent from my BlackBerry 10 smartphone on the Koodo network. >> Original Message >> From: Ilya Bakulin >> Sent: Thursday, February 11, 2016 10:43 AM >> To: Lundberg, Johannes >> Cc: Adrian Chadd; freebsd-hackers@freebsd.org; Alexander Motin; freebsd-= arm@freebsd.org >> Subject: Re: MMC/SDIO stack under CAM >> >> Hi Johannes, >> >> My work doesn't include writing drivers for SDHCI controllers. But if th= e controller on your new boards is supported by FreeBSD, then you can reall= y test the new stack! Especially if the controller driver for your board is= based on dev/sdhci, adapting it to work with the new stack is trivial. For= example, iMX6 SDHCI needed only a couple of lines: https://github.com/kiba= b/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 >> >> Please let me know when you get the new boards and we will figure out wh= at we need. >> >> On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" <johanne= s@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@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@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@freebsd.org mailing list >>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> > To unsubscribe, send any mail to " >>>> freebsd-hackers-unsubscribe@freebsd.org" >>>> > >>>> >>>> >>>> -- >>>> Regards, >>>> Ilya Bakulin >>>> >>>> >>>> >>> >>>-- >>>=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >>>=E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 >>>=E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >>>=E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >>>--- >>>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. >> >> -- >> =D0=9F=D1=80=D0=BE=D1=81=D1=82=D0=B8=D1=82=D0=B5 =D0=B7=D0=B0 =D0=BA=D1= =80=D0=B0=D1=82=D0=BA=D0=BE=D1=81=D1=82=D1=8C, =D1=81=D0=BE=D0=B7=D0=B4=D0= =B0=D0=BD=D0=BE =D0=B2 K-9 Mail. >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABx9NuRTB1L=APP=MrzvCWUGxw9=YJLoo7Nx_sJpavXJzoxfVA>