On Thu, 13 Jan 2011, Chuck Swiger wrote:
On Jan 13, 2011, at 8:54 PM, Bruce Evans wrote:
To quote an earlier post:
"Polling mode operation generally performs better when using older 100Mbs ethernet
NICs which do not support interrupt mitigation and various capabilities like TSO4;
gigabit ethernet NICs are smarter hardware and can generally outperform polling
mode."
I think "older 100Mbs" means "low-end 100Mbps". Mega-bit-seconds are
strange units, and 100Mbps NICs with enough buffers don't benefit much
from polling mode.
Insert a "/" into "Mbs" to get "Mb/s" if it makes you happier; I understand that some
folks insist upon adding a hyphen to "anal-retentive" for similarly pedantic reasons.
They even avoid dropping the *nix newline character
On a good day, my MUA sends "Content-type: text/plain; format=flowed" and
should contain line breaks following the 80-character-per-line Usenet conventions, which
modern MUAs might well reassemble based upon the user's window size. If it is being
re-interpreted after transmission by MTAs, mailing-list MIME filters, or similar, well,
that lies beyond my control.
Strangely, my MUA is sending format=flowed, etc., but mails received
from you don't have it. So when I reply to you and Cc me, then there
are enough newlines in the now-doubly-quoted original in the Cc.
format=flowed apparently even fixes up the quotes, so there are enough
quotes too. But I don't like this. Letting the MUA change the format
will mangle source code, diffs and some types of quotes. It would
take large markup to keep source code separate, and larger MUAs to
understand the difference between it and natural language. I normally
manually quote source code and diffs using "% ", but cvs commit mail
generators are not so careful and this causes problems with some MUAs.
[fxp's best of 100 Mbps NICs]
They have enough buffers (128 for each of tx and rx IIRC). The only thing
polling mode gave for them was lower latency, but this cost enabling
polling in the idle loop, which wastes 100% of at least 1 CPU and some
power. Without polling in idle, polling gives very high latency (even
worse than low-quality interrupt moderation does).
Here I can see some quote mangling, but mostly by my mailer:
- replies from you have my single ">" quoting preserved for adding one ">",
giving ">>". I think newlines line structure is preserved too.
- the Cc comes back with ">>" expanded to "> >" and another "> " for another
level. A few levels and there is no space for anything but quotes.
- something is not removing empty quoted lines at the end of quoted material.
One is visible in the above if it doesn't get mangled in the reply. This
is not as bad as adding extra empty lines between quotes.
Sure-- there are circumstances where a machine would always have traffic to
process, for which idle polling was beneficial to enable.
Yes, although polling was designed more to do the opposite -- to reduce
overheads by handling larger number of packets at time.
Bruce
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
