DragonFly BSD
DragonFly submit List (threaded) for 2006-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: re(4) update


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sun, 29 Oct 2006 09:40:26 -0800 (PST)

:Hi all,
:
:Main part of following patch is obtained from FreeBSD:
:http://leaf.dragonflybsd.org/~sephe/re.diff
:
:- correct eeprom accessing
:- support more 8169 based chips
:
:FreeBSD's re(4) turns off TX moderation by default, but I have seen
:netperf's UDP/TCP_STREAM noticable performance degradation in this
:way.  So a new per interface sysctl is added to turn on/off TX
:moderation on fly:
:hw.re0.tx_moderation
:It is _on_ by default.
:
:Please test/review it (it is against HEAD)
:If no objection comes, I will commit it one week later.
:
:Best Regards,
:sephe

    I think this is reasonable.  Frankly, I think some of the FreeBSD folks
    have gone off their rocker in their attempts to micro-optimize network
    benchmarks at the expense of cpu overhead.  It's just stupid.

    The classic trade-off here is that turning on interrupt moderation 
    greatly reduces cpu overhead while turning it off improves network
    throughput.  But I personally believe that the improvement in network
    throughput is SOLELY a function of the network driver design and
    that it is possible to redesign the driver to operate at maximum
    throughput with interrupt moderation turned *ON*.  But, instead of a
    thoughtful redesign, all I see coming out of FreeBSD development
    efforts here are hacks.

    Sometimes I wish I had a GiGE setup with sufficient bandwidth to
    actually run these interfaces at full speed.  Newer motherboards
    are getting faster slots and have more on-motherboard bandwidth so
    the problem of putting a working test environment together is slowly
    fixing itself.  But I still wonder what people think they are 
    accomplishing when the ONLY machine configuration where pushing full
    bandwidth on a GiGE link that really matters is a bridge or router
    configuration.  Everything else winds up being cpu bound, and if I
    actually HAD a critical application that required that kind of
    routing or bridging I would buy a dedicated piece of hardware to handle
    it, not try to use a general purpose operating system running on 
    commodity hardware.

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]