Jumbo Frames sort of working

[bj00]

Hi. I am working on a program to send jumbo frames at a fast rate using sockets over udp. I am using Fedora Core 5 - kernel 2.6.20-1.2320. So far this is what I've accomplished:

1.) The network adapter is set up to handle jumbo frames. Mtu = 9000.
2.) I can send repeated udp packets of size 8192 bytes broadcast over the network.
3.) Another computer on the network receives all of these packets...and their size if 8192 bytes.
4.) When I send these packets over the network I am using the sendto socket library call.
5.) Jumbo frame support seems ok at this point when I send this buffer repeatedly over the network with the size of the buffer set to 8192 bytes.
6.) At this point I start collecting data through some interface on my linux box and parsing the data and then sending this parsed data over the network, using udp....still using broadcast packets and packet size of 8192.
I have 4 buffers that round robin to put data into one buffer and fill up the next one once the previous one is full.
7.) At a packet size of 8192 bytes, the data in my buffer that I'm processing gets messed up (sort of like the hardware was filling the buffer with new data while I was processing it).
8.) At a packet size of 1500 bytes or less, the data in my buffer that I'm processing does not get mingled and all is well. More packets get sent per processed buffer when using 1500 vs. 8192 packet size. I can collect data in the round robin fashion and use the sendto(more calls for 1500 byte size vs. 8192 as my buffer is the same size) call to send the data. The receiver gets the data and it is all valid.
9.) What could be the cause of my data in my buffer getting mingled when I am calling sendto fewer times with a packet size of 8192 bytes vs. calling sendto more times with a packet size of 1500?

I'm new to linux and may be missing something that I'm hoping someone else knows off hand! My computer has 2 GB of memory, cpu is 3.2 GHz and my cache (in bios) says 512 KB - L2.

I did notice that there seem to be two different forms of linux - smp and the regular one. Would the smp version help out?

Any suggestions will be appreciated!

bj

[gogalthorp]

Can't help with the MTU problem. Sounds like a software design problem.

SMP is Symmetrical Multiple Processors. ie if you have more then one processor or cores you should run a SMP version of the Kernel to be able to use all the processors available. If you don't all process run on a single core.

There is also 32bit and 64bit versions. For most desktop uses 32 bit is fine and there are fewer problems ala 32/64bit drivers and software. But if you have a need for huge amounts of RAM you should use the 64bit (assuming your processor is 64bit)

[bj00]

My concern is with settings on Linux because when I run the program on a Windows XP system (2.2 GHZ, 960MB Ram), no problems occur. I would think it would be the other way around.

[gogalthorp]

Are you copying the buffer out before working on it. I admit that I know little about this, but it seems to me that you must somehow lock the buffer to keep the hardware from reusing it while you process or better copy the buffer to a new area to process. I assume what ever processing you are doing is relatively lengthy. IMO it is not a settings problem but a flow design problem. Differences in the OS's could simply be threading and priority based and the timeing simply happens to work in Windows. Could be wrong though.

[bj00]

Hi. I am copying the buffer out as I am parsing it. If I copy the buffer out all at once and then work on it, then there seems to be problems with overwriting buffers by the hardware again.
Hmmm. Do the hardware capabilities sound alright though? Do you think I might need different hardware? Would a dual processor work better for this type of processing on Linux?
Thanks for the suggestions!

[gogalthorp]

I don't believe this has anything to do with the hardware it is how you are handshaking with the OS. Multiple processors will only help when you have multiple independent threads ie vectorization. You need to find a form more directed to the programming in Linux.