防火墙x86架构和ASIC架构和NP架构的区别 zt

skipjack

原帖由 Jobs.AE@ 于 2006-4-27 15:05 发表


因为寄存器有两个通道，他一定要求对称分配！:em11:

呵呵~~~
对，测试要两次，第一次是在建立状态表，这个时候总是会慢一点，丢一点包，而后就快了！
老马的拉面确实难吃！
嗯，一半是多少呢？ ...

嗯...下次穿马甲

ydwoo0722

网络安全的处理应该是用多核的通用处理器比较合适，象RMI。现在的NP ASIC 之类的硬件加速方法一般就是把能够快速转发的连接放在硬件表中加速转发，在应用层处理日益增多的趋势下不合适。

2400 NP如果直接不外接高性能的CPU，而直接用XSCALE做主控CPU，在慢速路径（新建连接之类）的性能比较差。
XWALL ASIC连接表比较小，主控CPU如果用PPC405性能比较差，440还可以。

实际上用X86做性能也是可以的。用P4 3G + 82546光口 + PCI-X（64 * 66）吞吐率可以到小包双向35%(在NAT情况下），每秒新建9万个连接。在实际网络中，异常报文（需要递交CPU的报文）很多，X86可能比NP ASIC的还好用。

bingosek

老早就看过了
http://www.yesky.com/ServerIndex ... 419/1937606_2.shtml
转贴的也不注明出处，还能上精华，唉。。。。

zjzf_2

up

skipjack

原帖由 ydwoo0722 于 2006-5-15 00:36 发表
网络安全的处理应该是用多核的通用处理器比较合适，象RMI。现在的NP ASIC 之类的硬件加速方法一般就是把能够快速转发的连接放在硬件表中加速转发，在应用层处理日益增多的趋势下不合适。

2400 NP如果直接不外接 ...

你说的很对，但不是每个用户都明白这一点。一种新技术，首先是用户先发烧。随后才是厂商。

ydwoo0722

事实上，我觉得应该是
多核通用处理器+一些硬件算法引擎，如加解密引擎（IPSEC），模式匹配引擎（普通模式串或正则表达式匹配）。

难点在于，自己写的内核模块并行化的工作量大，同时非常难调试。锁的规划不合理（锁的粒度，CACHE的invalidate，memory barrier，pipeline stall），有时性能还不如单处理器。

skipjack

原帖由 ydwoo0722 于 2006-5-16 16:49 发表
事实上，我觉得应该是
多核通用处理器+一些硬件算法引擎，如加解密引擎（IPSEC），模式匹配引擎（普通模式串或正则表达式匹配）。

难点在于，自己写的内核模块并行化的工作量大，同时非常难调试。锁的规划不合 ...

以当前国内公司的质量管理水平看好，这么多的自主创新。很难保证新产品的稳定性了

zeroflag

没做过研发，对技术不是特别清楚。但是在使用中，NP在极限情况下还是靠的住的，尤其是在BT的冲击下。所以在大学里面我从来都是推我们NP的产品，而不是用通用CPU的产品。
一般的所谓NP防火墙，也是CPU+NP架构的，新建连接通过CPU完成，快速转发通过NP，小包达到2G应该没问题。尤其对长连接的BT，简直是得心应手哇。

Jobs.AE@

原帖由 ydwoo0722 于 2006-5-16 16:49 发表
事实上，我觉得应该是
多核通用处理器+一些硬件算法引擎，如加解密引擎（IPSEC），模式匹配引擎（普通模式串或正则表达式匹配）。

难点在于，自己写的内核模块并行化的工作量大，同时非常难调试。锁的规划不合 ...

想法不错，不过不现实，国内恐怕没有那个公司有这个实力。
如果这样发展，并发控制应该是下一步平台变更的最大瓶颈！

qintel

你看错了，这精华是给下面的讨论的，可不是给LZ我的。
这种文章没有多大技术含量，所以我只注明是ZT，而没有说是原出处。