Date: Fri, 23 Jan 1998 09:55:25 -0300 From: daniel_sobral@voga.com.br To: mike@smith.net.au Cc: hackers@FreeBSD.ORG Subject: Re: uiomove() Message-ID: <83256595.0045CB26.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> Er. Why do it that way? I presume that you are passed > a pointer to a linear region containing "plaintext", and > your task is to convert it into "ciphertext". Am I > close? > If not, then I assume that you have separate write and > read interfaces. Yep, I'm using separate read and write interfaces. > Can the card only handle one character at a time? How > slow is it handling a character/block? The card has single character and eight characters modes, but it is terribly slow in either mode. If I block everything until I finish the operation, I can gain about 20% in the 8 characters mode (which still must be feed one by one). As it is, both modes are taking almost the same time to process. The main problem is that I don't have a precise definition of how much time each operation takes. I only know some operations take up to a second to complete. The 512 bytes buffer I used to test the driver currently takes me 21 seconds to be processed, a reasonable amount of this time, it seems, taken by context switches. I plan to reduce it further using wakeup instead of 1 tick tsleeps (as I'm doing right now). > Do you (plan to) handle more than one writer at a time? Do > you synchronise writers and readers? The card is too stupid to handle multiple readers/writers (though I only realised that, and simplified the driver, after someone asked me how I saved context from stream to stream). I only accept one open() at a time. > Your calls won't be preempted unless another is called from an > interrupt context. What about SMP? > splsoftclock() is probably the one you want. Thanks. Still, I'd really appreciate knowing the difference between splsoftclock and splsofttty... > TBH, I would suggest that a "work queue" approach would be a > more efficient way to go, but this presumes on a single > crypt() call rather than seperate read/write calls. With > split calls, it becomes difficult to guarantee > synchronisation between multiple callers. A working queue was my first take on this, but since, as it is, it will gain me nothing, I decided on my current model. -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br Tagline: * FreeBSD. Earth.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83256595.0045CB26.00>