[Prism54-devel] [patch 0/6] [prism54 svn trunk] various fixes for prism54 svn

[Bruno Randolf]

hi jean-baptiste!

i guess i'm not a good representative for "real" embedded systems. the one i 
work with (http://meshcube.org) has a 400MHz CPU / 64MB RAM and thus is quite 
powerful compared to other embedded systems. 

but speaking of it, i just tested the performance of current svn + your 
patches: at 26-27Mbps, ksoftirqd_CPU0 uses 3 to 5 percent of the CPU. so i'd 
say performance is not really an issue, especially with hardmac cards. 

actually, while i am by no means an expert on that area, i don't really see 
the sense of scheduling a tasklet from within a tasklet.

but i hope that your patches make it into svn soon, since they make prism54 
useabe for me. thanks again :)

greetings,
bruno






On Tuesday 17 May 2005 17:34, Jean-Baptiste Note wrote:
> Hello Bruno,
>
> > platform: mips32 (au1500), little endian
> > kernel: 2.4.27
>
> Having read the prism2 driver, I'm contemplating another round of
> patches which would use another round of tasklets to do the rx job and
> probably increase performance and cache impact of the driver greatly.
>
> I'm thinking about :
> 1/ leave the interrupt handler as-is (after the patches !) -- it already
> does mimimum work.
> 2/ modify the update_tasklet so that it only acks the txs on tx queues,
> and on rx queues, queues the skbs for processing, refill the rx queues,
> signal the device and (if needed !) schedules 3 - 3'/ below
> 3 - 3'/ add a mgmt_rx tasklet and a data_rx tasklet that would dequeue the
> preceding skbs and process them in order.
>
> Gains :
> - clearer code
> - share code between the rx queues
> This can be done without all the tasklet thing, with only splitting the
> work into smaller functions.
>
> - we allow the device to resend frames as soon as possible on our part.
> - for mgmt frames, the big bunch of code processing them
> would only be loaded into cache when needed, that is, not very often.
>
> I'll do this if it can't be regarded as over-engeneering.
>
> Being on an embedded platform, have you got any problems with
> performance under heavy traffic (dropped packets, etc.) with the
> standard kernel driver, that would make those improvements worthwhile ?
> -- i guess that if you don't, those updates are unnecessary...
>
> JB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://prism54.org/pipermail/prism54-devel/attachments/20050517/efd46307/attachment-0001.pgp