From owner-freebsd-arm@freebsd.org Sun Feb 14 06:33:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D631CAA1EEF for ; Sun, 14 Feb 2016 06:33:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A9771C58 for ; Sun, 14 Feb 2016 06:33:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x22c.google.com with SMTP id b35so91221450qge.0 for ; Sat, 13 Feb 2016 22:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2oGWc7AJdraxIlkgbnO0MunnYNA7cVvU0j038dZXXSU=; b=CzLPOCGQPKpwQZ421T6E6iccd1uprnJQKO74VrioGlhOIM2GNsnRbLceM7FbMN8uPJ 1VTO0Wi8lC0TThukZDlJZc649qm3140L9gPCo0dX8pWuXZ77BkqGBhJtx5ztn+PA3KVc G4/h+GSzxOtYdkTdRVjdFmH3VdbxCsROU4zckyNbAXZikCzc6tAK0Z6nfVHtCdQ+cRpK o26uPzhKymLqNpRZY3E36daMYIAQJvTBfF62brV58emhSDFsJqTlPD+VmjcD4HBwPQTU OuOmv442cVtjJseKrh3lqv/fFYSMj6Y3XzalZCmw4lCwr5ASulQIULBJKXV81IyX1Oyz iZNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2oGWc7AJdraxIlkgbnO0MunnYNA7cVvU0j038dZXXSU=; b=RGVwIGjNtAfwifi3jVTL9OpWciOQRfHDTX6t0Ajs+WlLhSEzb9ABe0bMZPZEJOeQC5 t+dGrXqJMf5zPr7vxRIgphMb4XimyM3y7VLfTPWeidOlEI8cHaDgz/CbBXPh8qIRrWeQ 5xLL0hlZELkO0cLh5kR3eKJsevwmSdv4KXCcDLNHpkJwXZ8oxb+ftMcT3ILl1s69ZuHY 1+DczkGR+ctgjoylTbdOh92KMabkuM8hdTzqXqs6hNx7c2UFBeTHkl9eruxrUQYJ462U yjRBIn7gCXIVadC1a9oiKW1PsaIT9iQqPDqDljYctPWX2QYlMfsPjXTNUvNGiEf2Zl22 bh7g== X-Gm-Message-State: AG10YOQY7ajTRqTTSHfKhw4Ekuk+Umb8MMRbcsm9YNr4jQT1EAplFvxDTbeWkLg+NQ/GQib2tGSLnGi2m3Q9pA== MIME-Version: 1.0 X-Received: by 10.140.43.180 with SMTP id e49mr12408377qga.50.1455431632730; Sat, 13 Feb 2016 22:33:52 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Sat, 13 Feb 2016 22:33:52 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> <20160213035806.4403283.12124.2928@gmail.com> Date: Sat, 13 Feb 2016 23:33:52 -0700 X-Google-Sender-Auth: KSjFZ3rwBFFvi9Y9ZYRqGsWEuvU Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Warner Losh To: Russell Haley Cc: Adrian Chadd , "freebsd-hackers@freebsd.org" , Alexander Motin , Ilya Bakulin , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 06:33:53 -0000 On Fri, Feb 12, 2016 at 11:48 PM, Russell Haley wrote: > On Fri, Feb 12, 2016 at 8:16 PM, Adrian Chadd > wrote: > > On 12 February 2016 at 19:58, Russell Haley > wrote: > >> Hi Ilya, so does that mean I can take a linux driver for an SDIO wifi > card and build it using a reference to your library and everything should > "just 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? > "camcontrol devlist" would let you know for sure. Warner > 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 > the controller on your new boards is supported by FreeBSD, then you can > really 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/kibab/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b= 60db0e9 > >> > >> Please let me know when you get the new boards and we will figure out > what we need. > >> > >> On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" < > johannes@brilliantservice.co.jp> wrote: > >>>Hi Ilya > >>> > >>>This is great! > >>> > >>>I've got a Tronsmart ARA X5 and just purchased a few UP > >>> > >>>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 > >>>Facebook > >>> Reddit > >>> Twitter > >>> GitHub > >>> > >>>GitLab > >>>Company: Mirama Brilliantservice US > >>> Brilliantservice JP > >>> > >>> > >>>On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin 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 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 i= s > >>>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" > _______________________________________________ > 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" >