GSoC'18 proposal - Porting SDIO driver and benchmarking

[Udit agarwal]

Hi,

On Sun, Mar 18, 2018 at 8:48 PM, Christian Mauderer <list at c-mauderer.de>
wrote:

> Am 18.03.2018 um 14:22 schrieb Udit agarwal:
> > Hi all,
> > Here's the link to my proposal:
> > https://docs.google.com/document/d/15Ut9FLAV3Y0Up1Qn02ys6KAb2QhtR
> eF_P-wNR861NMo/edit?usp=sharing
> >
> > Please have a look, and comment where ever needed.
> > I tried my best to make time-line as realistic as possible. Please feel
> > free to comment in case of any unbalance or overlooked task.
> >
> > Regards,
> > Udit agarwal
> >
> >
>
> Hello Udit,
>
> some (not too well sorted) notes:
>
> 1. One point I'm missing is the target that you produce a set of patches
> that can be easily merged as soon as the libbsd receives it's next
> update. Otherwise the only result from that project would be the
> comparison document.
>
> That's a really good idea! I have now included that in my proposal, please
have a look.

>
> 2. I'm not sure whether the point
>
>   "Backport the SDIO driver residing within the mmccam stack to FreeBSD
> version being used by libbsd"
>
> is a good idea. It sounds like you want to do the backport on FreeBSD.
> You most likely would have a lot of work with that without any really
> useful results. It would be better to analyse whether some other
> subsystems might have an influence on the performance measurement (which
> I would expect to be quite few) and then do the backport directly on
> RTEMS libbsd.
>
> Noted. I have corrected this. Moreover, i am studying several files
<http://blog.uditagarwal.in/index.php/2018/03/19/implementing-a-mmc-sd-sdio-stack-using-cam-framework/>
changed/modified during
the mmccam commit and as of now, i didn't  came across any such Non-RTEMS
dependency
that might affect systems performance. I have a query here, in RTEMS-libbsd
<https://github.com/RTEMS/rtems-libbsd/tree/master/freebsd/sys/cam> cam
directory, there are some files
like cam.h and cam_ccb.h belonging to different FreeBSD head versions. Is
it because, since there has been no change in the file, so its not updated?

>
> 3. It seems that you have split up the test bench over all three phases.
> It might would be more efficient to search a test bench and get it
> running on FreeBSD as well as on RTEMS quite early. There should be no
> difference whether it runs on the old SD-card driver, the SDIO one or
> some USB stick. It should basically work with with any block device.
>
> If you start to port it to RTEMS in phase 3 and then find out that it
> doesn't work like expected, you will have to restart with searching some
> other test bench. This would mean that you can throw away all results of
> the workbench that you collected in between.
>
> I have corrected this. So, now the first phase, I'll be porting SDIO
driver, and in the second and third phase, I'll focus on the benchmarking
task. Hopefully, now we have ample time to fallback and search for another
benchmarks in case the first one didn't work expectedly.

>
> 4. I'm not quite sure whether the amount of work would really fill all
> three phases. Maybe you should plan an extended goal. With that topic
> that could for example be a benchmark for some other drivers (like USB
> storage).
>
> Done.

>
> 5. Currently your results are a document and a set of patches that
> (hopefully) can be integrated into libbsd in the future. I think that if
> you find some good standard performance test for block devices, porting
> that could be another core result that can be integrated directly and
> not only after a libbsd upgrade.
>
> I came across several popular, multipurpose I/O benchmarks like IOZone and
IOrate with compatible license(1
<http://www.iozone.org/docs/Iozone_License.txt>,2
<https://sites.google.com/site/vwiorate/home>). Since, these are FreeBSD
compatible probably they will work. Still, I have added 'Searching and
testing benchmarks on FreeBSD' as one of my goal.

> With kind regards
>
> Christian Mauderer
>

Regards,
Udit agarwal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180320/f827966b/attachment-0002.html>