Gilboa Davara wrote:
Let's try to analyze them together - you need to store large amount of
data from the network for proccessing by a further entity. What that
data is exactly doesn't matter, but we will note that you might need to
do non trivial handling of the data (encryption).
I should add the encryption optional, depending on load and source. (And
more important, how fanatical is the client)
(There's no way in hell, I'll be able to process and encrypt two OC48
links in real time...)
I believe you can, but this WILL require much more explanation...
So long as you didn't perform 2, you want the information to wait in a
temporary buffer (I first wrote "bugger" here, which is rather funny ;-)
until you're done with it so store the data in a temporary in kernel
buffer (or bugger, if you prefer ;-), have a user space proccess read it
from there, proccess it, encrypt it, write it to file.
Have yet another proccess send it to the thrid party (possibly using
the Linux sendfile syscall for efficincy).
Now you can write that "Temporary buffer layer in kernel that can easily
be read by user space: your self but you'll be just wasting DOOM3
cyclesw. This is exactly RelayFS. The rest are simple user space
programs (and if you want to see an example on how to use it see Karim's
most excellent LTT tool that can use RelayFS: http://www.opersys.com/LTT).
Interesting... that might work.
Let me first point out that once the cells/frames have been processed, I
don't care much for timing. (Which bodes well on your solution).
However, I'm ****very**** tight on CPU and memory bandwidth. (Even a
dual Opteron machine with two memory banks tends to suffocate at a
certain point.)
No matter what I do I just can't afford to add memcpy's to my system.
Understandable attitude, but it may be wrong. Take a look at this paper
from last year OLS for example:
http://www.linuxsymposium.org/proceedings/reprints/Reprint-Ronciak-OLS2004.pdf
These guys from Intel thought having a zero copy receive path for
network packets where the card will DMA stright into the user space
program buffer will be a big win due to saving a memcpy.
They implemented and tested. Results? perfomace was *worse* from losing
the extra copy, not better. It turned out the extra copy actually
pre-loaded the cache and gained more then it costs.
Does this fit your scenario? I have no idea. But there is a lesson here:
don't assume anything. Build a quick pilot and measure. You may very
well find out that your bottle necks are completly different areas (for
example - are your network drivers interrupt driven? you might very well
find that your system gets into live lock on interrupts before any
issues stemming from memcpy of data).
As the man said, pre optimization ios the root of all evil.
Here's how I see it:
Kernel 1:
Device -> SKB -> Reassembly -> Disk.
(I can even save the third memcpy [Reassembly -> Disk] I go rewrite the
world under me)
User:
Device -> SKB -> Reassembly ( -> ?) Relayfs -> User: write(2) ->
Kernel: sys_write (copy_from_user) -> Disk.
As I already said, you can use Linux sendfile() to avoid the last copy
if you're not messing with the data after it reached the disk. Wont help
the decryption case, unless you also happen to have a a hardware
encryption engine, which is a good idea anyways.
Oh... Thanks for the help. I appreciate it.
Thanks for the interesting subject :-)
Gilad
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
Codefidence. A name you can trust(tm)
Web: http://codefidence.com | SIP: [EMAIL PROTECTED]
IL: +972.9.8650475 ext. 201 | Fax: +972.9.8850643
US: +1.360.2275194 ext. 201 | Cel: +972.52.8260388
"I am Jack's Overwritten Stack Pointer"
-- Hackers Club, the movie
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
