Take that with a grain of salt.
A common misconception is an embedded ASIC on hardware such as a NIC or
RAID card will be faster than performing those functions in software
using the host CPU. This is certainly not always the case and there are
some examples that can be found online where enabling TOE features can
actually slow things down.
There are a number of factors that come into play here. If you don't
have any CPU available, then any offloading to an ASIC for anything such
as TOE will likely help. Also if the TCP/IP stack implementation in the
core OS is shall we say suboptimal, then offloading could help. Also the
driver implementation and driver parameters can play a huge role under
high packet loads.
I have some Intel 10Gbe NICs running on Linux in my NetBackup
environment which do around 2-3gbit/s. Enabling or disabling TOE doesn't
seem to make much of a difference. I find most CPU time is spent in the
kernel flipping the 100k+ context switches/second required to schedule
all of those bptm processes and then there's the added latency of
interrupt generation and FC protocol overhead when sending out my HBAs.
Even so, I still have plenty of CPU available and usually saturate my
tape drives. This is a 4 x Xeon 3ghz box for reference.
The best advantage some of the higher end NICs have (although this is
even becoming common place these days) is interrupt coalescing since it
gets rather expensive to generate a hardware interrupt for every packet
at high packet rates.
In short YMMV highly is a given. Unless you are currently saturating
your CPUs I would be pretty skeptical, but I would be curious to see
your results.
DC-
>-----Original Message-----
>From: veritas-bu-bounces at mailman.eng.auburn.edu [mailto:veritas-bu-
>bounces at mailman.eng.auburn.edu] On Behalf Of "Koster, Phil"
>Sent: Thursday, September 07, 2006 8:16 AM
>To: JMARTI05; veritas-bu
>Subject: Re: [Veritas-bu] TNICs?
>
>I brought this up to one of the other network engineers and got this
>response:
>
>"http://www.alacritech.com/html/SEN2100_Accelerator.shtml
>
>These are worth every penny. Before The Exchange server got gigabit our
>intel nic's were killing us. After I put these in speed was not an
issue."
>
>Phil Koster
>Network Administrator
>City of Grand Rapids
>Direct: 616-456-3136
>Helpdesk: 456-3999
>
>-----Original Message-----
>From: JMARTI05 at intersil.com [mailto:JMARTI05 at intersil.com]
>Sent: Thursday, September 07, 2006 9:45 AM
>To: veritas-bu at mailman.eng.auburn.edu
>Subject: [Veritas-bu] TNICs?
>
>Have anyone done any testing with TOE Nics? (TCIP Offload Engine)
>Basically a "beefier" hardware Nic that does the packet disassembly in
the
>Nic w/ Hardware as opposed to waiting for the Software / OS. We're
looking
>at outfitting our new Media servers with Quad Copper Gigabit TOE Nics
>(PCIe/4) and I'm quite interested to see if the extra $1000 per nic is
>worth the cost from a speed perspective. I read on a whitepaper on how
2
>TOE Nics outperformed 4 gigabit nics in a pure data transmission /
speed
>test, but it didn't look terribly reliable. I'm planning on running
>several rounds of data performance testing of all my hardware when the
new
>hardware arrives, but I'm wondering if anyone here has done any testing
of
>their own?
>
>-Jonathan
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
>_______________________________________________
>Veritas-bu maillist - Veritas-bu at mailman.eng.auburn.edu
>http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
*****************************************************************************
Note: The information contained in this message and any attachment to it is
privileged, confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify
the sender immediately by replying to the message, and please delete it from
your system. Thank you. NYSE Group.
|
