[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] FSL Driver Overhead

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I rechecked my implementation and realized that I had made a mistake. I didn't have a conditional statement to output the number of waits (the driver was taking longer because it printed out each call, and thus the FIFOs were always ready).
After changing both the read and write drivers to count properly, I receive a report of about 240 read waits (encrypting 700KB of data) at various times during the encryption process. I've been able to get my transaction count down to 4 writes and 4 reads per 128 bits of data.
I also tried the same process, but with a hardware block that just immediately wrote back a number to the FSL link once one was received. However, about the same number of read waits were reported. This should not be the case, because the hardware immediately writes results back to the FSL. 

My driver implementation uses the example that Claudio suggested:

For Reading:
(...)
if(fsl_fifo->rx_cnt<FSLFIFO_BUF_SIZE)
                        {
                                restore_flags(flags);
                                do_reschedule++;
                                break;
                        }
                        restore_flags(flags);
(... End of function)
if(read_empty_counter !=0) printk("The number of read waits is %i \n",read_empty_counter); 

Writing is basically the same.
When I want to read and write to the FSL: (This is done only once during the whole program's run) 

{
key->fd = open(FIFO_DEVICE, O_RDWR);
int arg;
arg = 4;
key->rv = ioctl(key->fd, FSLFIFO_IOCTWIDTH, arg)
}

For reading and writing (two examples):

key->rv = write(key->fd, &rk[i], sizeof(rk[i]));
key->rv = read(key->fd, &s0, sizeof(s0));
Are there any reasons that you guys can think of that might be registering as the delays? I may check out the hardware with chipscope, but I can't see the hardware taking that long. It takes the hardware 3 cycles per write to the FIFO (6 cycles from initial read to writing the same number back).
Is my implementation of FIFO reading broken? Any other reason why would this be taking so much time? 

Jonathan

- -------------------------------------
Jonathan Jung
jwjung@xxxxxxxxxxxxx
jonathan.jung@xxxxxxxx

My public key is available on http://www.keyserver.net/en/

On Jan 4, 2006, at 6:03 PM, jonathanjung wrote:


Thanks guys!
I've recorded the number of times the fsl is full (or empty) and come up with a bunch of zeros. I'll need to double check my implementation, but this seems likely because of the new fifo depth of 64 words.
I'm going to test my implementation by writing a test app that purposely tries to read and write to an empty/full fifo. 

-----------------
Jonathan Jung
jwjung@xxxxxxxxxxxxx
Sent via Chattermail - push Email for the treo

-----Original Message-----
From: Claudio Lanconelli <lanconelli.claudio@xxxxxxxxx>
Date: Wednesday, Jan 4, 2006 6:18 am
Subject: Re: [microblaze-uclinux] FSL Driver Overhead

Hi Jonathan,
Inside kernel you can't use printf, but you can use printk() that is printf() with some limitations. Howerver to print integer variables you can consider exactly like printf() 

For example:
printk("Write full count: %d, Read empty count: %d\n", write_full_counter, read_empty_counter); 

Cheers,
Claudio Lanconelli

Jonathan Jung wrote:


-----BEGIN PGP SIGNED MESSAGE-----

 Hash: SHA1


Hi Claudio,



One question regarding the counter:
I'm not really familiar with Linux driver development, but is there an 
 easy way to gain access to printf from inside the driver (fslfifo.c)?
 Including uClib's stdio.h leads to a large mess of files that would
 have to be copied/symlinked to different locations.


Should I be reading the value of the counters a different way?



Thanks,



Jonathan





 On Jan 3, 2006, at 2:55 AM, Claudio Lanconelli wrote:


Jonathan Jung wrote:
As you can see, software version consumes 1m 33 s of CPU time >> running the openssl code. The hardware/software combo takes only 10 >> seconds of time executing the openssl code, but requires 1 minute >> and 56 seconds of overhead in unrelated system calls, I'm sure is >> because of the reading and writing to the FSL.
Reading/writing to FSL takes time only when the FSL FIFO if full on > writing or empty on reading. Be sure your FSL FIFO is depth enough. Then you can count how many > times the driver wait on the 
fifo by adding a couple of counters like this:

write_tasklet_func:

fsl_nput(fsl_fifo->id, value, fsl_status);
if(fsl_nodata(fsl_status))
{
write_full_counter++;
do_reschedule++;
break;
}

read_tasklet_func:

fsl_nget(fsl_fifo->id, val, fsl_status);
if(fsl_nodata(fsl_status))
{
read_empty_counter++;
break;
}

Try it and report the counters value

Happy new year,
Claudio Lanconelli
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze- uclinux Mailing List Archive : http://www.itee.uq.edu.au/~listarch/ > microblaze-uclinux/ 




 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.1 (Darwin)


iD8DBQFDu4Dd4kOt3FHegqgRAtgzAJwP8BfAWhlyphrZJiRKQg1BqMKD1ACglH9O

 k9Ejyjeb+M5qmJnm5sTHtFo=
 =Jo9p
 -----END PGP SIGNATURE-----
 __________________________

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze- uclinux Mailing List Archive : http://www.itee.uq.edu.au/~listarch/ microblaze-uclinux/ 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFD0fwx4kOt3FHegqgRAlwmAKCKm51BQYK6PqJjKxjfBHMr53EX8gCfaLTC
9bmNudB1+alqkTmwbDId7ts=
=xwBT
-----END PGP SIGNATURE-----
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/