>From: David Lawless [mailto:[EMAIL PROTECTED] >>IOAT DMA offloading works for TCP only. It does not support UDP. >>Only large buffers are offloaded to DMA engine (> 4kB). >>DCA is a different feature that supports endpoint device to >>memory writes and it works regardless of transfer size. > >Maciej, > >It seems to me that with the 5400 chipset, the original I/OAT >hardware interface has gone away. The 'ioatdma.ko' device >driver depends on 'dca.ko', so it likely is a situation where >the I/OAT API is still presented to the kernel but the >underlying mechanism is DCA.
The 5400 chipset has the 2nd generation ioatdma as well as the dca functionality. The kernel patches to support both went in about a year ago. This current ioatdma driver supports both the 1st and the 2nd generation ioatdma hardware. The dca driver does not take part in the dma activities directly. It allows a NIC driver to hint to the CPU cache that a chunk of data is available that should get put into the cache before the CPU needs it. This is probably data that was recently dma'd. > >The 4KB size can be adjusted downward with the >'net.ipv4.tcp_dma_copybreak' 'sysctl' parameter--I've set it to >zero bytes. > >I've seen some Kernel.org messages which indicate that UPD will >eventually be supported. Are you refering to this thread: http://marc.info/?t=119636731700001&r=1&w=2 ? This is from work done in a student project that we made available to the community but didn't followup. Please feel free to see if that code helps your situation, but be aware that is has not gone through very much test. >The real point of my question is how effective the new DCA >mechanism will be at mitigating CPU for small packets. Of >course the device-to-memory aspect of DCA looks promising, but >I'm starting to wonder if it really makes any significant >difference. This is one of those situationally specific performance questions. The tuning for specific packet sizes becomes very dependent on the speed of the current FSBs, memory, and CPUs. You will probably have to experiment a little before deciding what works best for your individual problem. sln ====================================================================== Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED] I don't speak for Intel (503) 712-7659 Parents can't afford to be squeamish. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
