g****u
发帖数: 252 | 1 昨天已经把机器找出来了，还没装系统。到时候用来测老魏的服务器。
有同学愿意一起折腾吗？
我好无聊。 |
t**********1
发帖数: 550 | 2 赞一个。我给你一个建议。mTCP的threading model完完全全错了。
你要是能给改对了，绝对是大成绩。当然了，这也是大工程。 |
g****u
发帖数: 252 | 3 我先跑起来再说。已有啥证据证明用户态stack将来有用吗？
我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
CPU没有cycle可以用来干别的事情了吧？
【在 t**********1 的大作中提到】
: 赞一个。我给你一个建议。mTCP的threading model完完全全错了。
: 你要是能给改对了，绝对是大成绩。当然了，这也是大工程。
|
t**********1
发帖数: 550 | 4 用户态是必须的。TCP offload不矛盾，但是能做的有限。
CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
但是一定要100%用户态。
你要CPU干啥？I/O也就一个core。你有多少core?
【在 g****u 的大作中提到】
: 我先跑起来再说。已有啥证据证明用户态stack将来有用吗？
: 我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
: CPU没有cycle可以用来干别的事情了吧？
|
g****u
发帖数: 252 | 5 这个我不懂。我先玩两天再说。
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
|
j******a
发帖数: 100 | 6 NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
poll包的
我还是没有领会用户态有什么逆天的优势
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
|
t**********1
发帖数: 550 | 7 用户态latency最低，throughput最高。
网卡所做的就是pool packets，等用户poll就好了。
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
|
b*******s
发帖数: 5216 | 8 less copy
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
|
m*f
发帖数: 3078 | 9 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
dpdk现成的产品好多年
dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
|
T********i
发帖数: 2416 | 10 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
Hugepage和numa之类的优化我也玩了很多年了。
老兄貌似是搞这个方向的，有兴趣一起折腾么？
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
|
|
|
c*a
发帖数: 806 | 11 很好奇。这方面商业产品很多。现在主要还剩下什么？
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
|
T********i
发帖数: 2416 | 12 我也是孤陋寡闻。用OnLoad轮子用惯了。
想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
纯粹扯淡。
看来您是行家，能不能介绍下靠谱的商业产品？
【在 c*a 的大作中提到】
: 很好奇。这方面商业产品很多。现在主要还剩下什么？
|
m*f
发帖数: 3078 | 13 我只能给魏老师提鞋了，过两个月吧，我有时间和你联系
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
|
T********i
发帖数: 2416 | 14 您过谦了。承受不起。等你消息。
【在 m*f 的大作中提到】
: 我只能给魏老师提鞋了，过两个月吧，我有时间和你联系
|
g****u
发帖数: 252 | 15 我看了mTCP的paper。这货的目的是要代替内核TCP。threading model和别的一系列
design decision都是按这个目的做出的。作为一个用户态的通用的TCP库，需要实现
两点：
- 库本身不能霸占着CPU不放。因为用户程序可能也要跑CPU。所以mTCP是基于event
而不是polling的。mTCP本来应该是从PSIO(event)开始做的。DPDK应该是后来加上去的。
DPDK是polling。
- 不能假设逻辑线程<=物理线程。对于有的应用，逻辑线程可能是物理线程的
好几倍，靠send/recv阻塞的时候操统调度来提高硬件利用率。我那个客户端就是
这么干的。
这个paper里提到了context-switch。这是很明显的一个indicator: paper里讲的
线程是逻辑线程。如果限制线程数绑定CPU，mTCP应该可以做成context-switch-free的。
不过得把pthread那套同步机制全都换掉才行。
关键还是通用 vs 专用的问题。如果做成专用的话，paper估计就发不出去了。
其实写paper的时候把PSIO换成DPDK，review就会出问题。
model
【在 T********i 的大作中提到】
: 我也是孤陋寡闻。用OnLoad轮子用惯了。
: 想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
: 纯粹扯淡。
: 看来您是行家，能不能介绍下靠谱的商业产品？
|
n*******7
发帖数: 181 | 16 最近可能有Cavium Networks的DPDK的工作机会。按他们的说法，Intel的DPDK很多做法
还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
作是不是太窄了。 |
w***g
发帖数: 5958 | 17 你要看成是专搞DPDK的话确实比较窄。
你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
DPDK用到的几个技术都可以用来优化别的软件。
现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
吗？
【在 n*******7 的大作中提到】
: 最近可能有Cavium Networks的DPDK的工作机会。按他们的说法，Intel的DPDK很多做法
: 还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
: 我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
: 利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
: 作是不是太窄了。
|
n*******7
发帖数: 181 | 18 多榭wdong！
用DPDK做各种应用不窄。做DPDK的内部工作可能还是较窄的。
用C语言写系统程序，听起来很普适。但具体做起来，大多数是用具体硬件环境的
proprietary知识，而不用常见的轮子，所以虽然系统性能指标做高了，但在简历上看
起来较偏，反而比不上用轮子的适用面广。
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
|
b*******s
发帖数: 5216 | 19 现在这个经济趋势，互联网泡沫离破也快了，到时会平衡一点
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
|
N*****m
发帖数: 42603 | 20 scylladb有dpdk的driver，有点意思
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
|
n******t
发帖数: 4406 | 21 latency呢？我觉得要追求pps这种东西可以做聚合就行，为什么要poll cpu啊？
总之我觉得dpdk是intel的思维方式，不太感冒。
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
|
