MMC/SDIO stack under CAM

[Ilya Bakulin]

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

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