[Asterisk-Dev] TCP/IP Gigabit Ethernet accel. question

Kevin P. Fleming kpfleming at starnetworks.us
Sat Feb 12 18:49:32 MST 2005


John Todd wrote:

> blah blah blah - I lead with too much intro information.  Let's get to 
> the "-dev" part of this, shall we?   A hardware manufacturer has 
> mentioned to me that they have a TCP/IP stack and hardware interface 
> card (gig e) which will improve performance up to 70% in a way that is 
> transparent to the application.  It's a series of patches on RH9.0 which 
> provides this capability.  The card has two Gig-E ports, and one would 
> assume that an administrator would have two "sides" of their network 
> (public/private? SIP/H323?) balanced, one to a port.

Sorry to burst your bubble, but SIP and RTP run over UDP, not TCP. Doing 
any sort of TCP offloading to the card will have little impact.

In addition, this topic comes up frequently on the Linux kernel mailing 
list, and it is always shot down, because if you move any part of the 
TCP handling to the NIC, you are:

- no longer open source
- have no control over the stack for security issues
- have no way to improve performance by improving the rest of the system

As it stands today, there are a number of technologies that exist on 
NICs that already help with the issue you are describing:

- NAPI reduces the interrupt load by "coalescing" multiple received 
packets into single interrupts

- IP checksum offloading does the obvious: relieves the CPU of having to 
calculate/check the IP checksum

- scatter/gather transmission allows the kernel driver to push a list of 
packets out to the NIC located all over memory space and have them 
transmitted by the NIC

The remaining issues are UDP checksumming (which the Linux kernel does 
at basically zero cost as it copies the packets into userspace memory), 
and poll/select/epoll overhead. The latter could be reduced by creating 
a dedicated "RTP bridge" thread in Asterisk and letting it handle all 
concurrent RTP bridging, so that a single poll()/epoll() call might 
return status for dozens of active sessions, rather than handling only a 
single one.



More information about the asterisk-dev mailing list