DP performance

[Matthew Dillon]

:The issue is that RX is absolute, as you cannot
:"decide" to delay or selectively drop since you
:don't know whats coming. Better to have some
:latency than dropped packets. But if you don't
:dedicate to RX, then you have an unknown amount
:of cpu resources doing "other stuff". The
:capacity issues always first manifest themselves
:as rx overruns, and they always happen a lot
:sooner on MP machines than UP machines. The LINUX
:camp made the mistake of not making RX important
:enough, and now their 2.6 kernels drop packets
:all over the ranch. But audio is nice and
:smooth... 
:
:How to do it or why its difficult is a designer's
:issue. I've not yet been convinced that MP is
:something thats suitable for a network intensive
:environment as I've never seen an MP OS that has
:come close to Freebsd 4.x UP performance.
:
:DT

    RX interrupts can be hardware moderated just like TX interrupts.
    The EM device, for example, allows you to set the minimum
    delay between RX intrrupts. 

    For example, lets say a packet comes in and EM interrupts immediately,
    resulting in a single packet processed on that interrupt.  Once the
    interrupt has occured EM will not generate another interrupt for N
    microseconds, no matter how many packets come in, where N is programmable.
    Of course N is programmed to a value that will not result in the RX
    ring overflowing.  The result is that further RX interrupts may bundle
    10-50 receive packets on each interrupt depending on the packet size.

    This aggregation feature of (nearly all) GiGE ethernet devices reduces
    the effective overhead of interrupt entry and exit to near zero, which
    means that the device doesn't need to be polled even under the most
    adverse circumstances.

    I don't know what the issue you bring up with the Linux kernels is,
    but at GigE speeds the ethernet hardware is actually flow-controlled.
    There should not be any packet loss even if the cpu cannot keep up with
    a full-bandwidth packet stream.   There is certainly no need to fast-path
    the network interrupt, it simply needs to be processed in a reasonable
    period of time.  A few milliseconds of latency occuring every once in a
    while would not have any adverse effect.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>