Paul Durrant wrote:
> Garrett D'Amore wrote:
>
>> If I were writing a 10GbE driver, I'd use direct DMA mapping for Jumbo
>> frames, but I'd stick with bcopy/mcopymsg style for regular MTU frames
>> -- at least until someone convinced me that doing otherwise was worthwhile.
>>
>>
>
> DMA overhead depends on the architecture. Agreed that copying is almost
> certainly going to be faster on a SPARC system where you have an IOMMU
> to worry about, but DMA setup on an x86 is pretty cheap on many
> implementations and so mapping small packets can still be worthwhile to
> reduce CPU utilization.
> Bear in mind that for a 10G interface CPU utilization is everything.
> E.g. if you move from a netperf instance being able to saturate a 10G
> interface using a single CPU core from it taking 2 CPU cores, your
> benchmark performance can fall off dramatically.
>
But going forward, more and more x86 architectures are moving towards
IOMMUs (for virtualization, mostly, but there are some other benefits as
well), so the simple architecture of 1 and 2 CPU x86 boxes seems like
maybe not a good idea to depend upon.
Of course, it also requires that the buffers be mapped somewhere in low
physical address space, or you have to have a driver that can address
the entire region of physical memory (i.e. 64-bit support on the
adapter) to avoid the use of bounce buffers on systems without IOMMU
capability.
So, I guess that means, on some specific platform and NIC combinations,
DMA may be more attractive. And at 10GbE, it probably is worth making
this optimization available to customers. (Although I'd have it not
even compiled into the SPARC binaries -- every branch taken, even just a
quick test against a boolean, adds to the run path length, and
ultimately reduces the number of small packets per second that be sent.
-- Garrett
> Paul
> _______________________________________________
> driver-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
