BSDNow网站访问sepherosa Ziehau

dragonflyseallyhs 发布于 2015/06/16 10:20
阅读 316
收藏 0

日前美国BSDNow网站访问了DragonflyBSD开源组织的Sepherosa Ziehau,我们来看看这次访问都说了些什么?


1、 主持人:能简单介绍一下你自己吗?你是如何接触到BSD的?

 乔:我是一名程序员,我现在生活在中国上海。我在大学的时候第一次接触到BSD,当时我的一个同学把FreeBSD介绍给我。在此之前我只用过Linux,这之后我就只使用BSD了。在大学里,我曾使用过NetBSD和OpenBSD,但是我还是比较喜欢FreeBSD。在毕业之后,我开始进行DragonflyBSD相关的开发工作。

 2、 主持人:DragonflyBSD有哪些吸引你的地方?

 乔:Dragonfly对网络堆栈的处理方式非常巧妙,同时Dragonfly社区友好的氛围也具有吸引力。并且你可以从Dragonfly的标志性人物Matthew Dillon和Jeffrey Hsu那里学到很多。

 3、 主持人:在DragonflyBSD开源项目里,你主要从事哪个方面的开发?

 乔:在DragonflyBSD开源项目中我主要从事网络相关部分的开发工作。从内核的套接字到网络设备驱动。我从其他BSD项目里移植了很多网络设备驱动,同时我自己也写了不少网络设备驱动。在过去3年里,我在Dragonfly上实现了更多的TCP相关的RFC并且改善了Dragonfly网络堆栈的并行度。我还对Dragonfly的其他部分进行开发,比如,APIC,能耗管理,中断分配以及其他一些硬件相关的东西。实际上很多开发工作是为了让我的新计算机在Dragonfly上更好的工作。

 4、 主持人:DragonflyBSD的网络堆栈和其他的网络堆栈的主要区别在哪里?

 乔:有别于其他系统,Dragonfly的网络堆栈不使用锁进行保护。Dragonfly使用消息传递和线程来序列化网络操作,每个CPU有自己的专用线程来处理网络操作。有些网络数据在每个CPU上有一份独立的拷贝,比如路由表。有一部分网络数据被划分到不同的CPU上,比如,TCP和UDP的控制数据结构。有些数据则在每个CPU上独立操作,比如,TCP/IP的统计数据。

  我来举几个简单的例子。

  如果应用程序要发送数据,那它就发送一个消息到CPU专属的网络线程。该网络线程进行所有的网络协议处理,并最终通知网络设备发送处理完的数据包。另一方面,当网络设备接收到一个数据包时,Dragonfly或网络设备对该数据包生成一个哈希值。这个哈希值用于选取一个CPU专属的网络线程。之后接收到的数据包就被投递到选中的CPU专属网络线程。该线程完成所有的网络协议处理后,将数据放到应用程序套接字的接收数据缓冲中。

 5、 主持人:能否介绍一下DragonflyBSD网络堆栈的优势和缺点?

 乔:Dragonfly网络堆栈的优势比较显而易见。Dragonfly的网络堆栈不使用锁进行保护,因此没有和锁相关的竞争,而且锁序问题完全不用担心。当你开发类似TCP这样的复杂的系统时,不使用锁的优点就非常明显了。另一个优势是,不同CPU之间缓冲的干扰相当低。因为网络数据要么被划分到不同的CPU上,要么被复制到每个CPU上,或者在每个CPU上独立操作,每个CPU只访问和修改自己的数据。其次,因为所有的网络操作都在一组固定的线程中运行,所以类似数据包传输聚合和TCP ACK聚合实现起来非常简单。

   当然每个系统都有自己的缺点,Dragonfly网络堆栈也有自己不足的地方:部分网络数据在每个CPU上的复制会增加内存使用量。比如说,完整的BGP路由表相较其他基于锁的系统在Dragonfly上会消耗更多内存,因为Dragonfly在每个CPU上把路由表复制一份。但是对现在的硬件来说,额外的内存开销通常并不成问题,因为现在内存其实相当便宜。使用很多CPU的计算机通常会配备更多的内存。

   你可能看到过一些早期的网络研究说线程序列化的网络堆栈由于线程调度开销会比基于锁的网络堆栈慢。Dragonfly在数年前也发现了这些研究所提及的线程调度开销。但是我们发现高线程调度开销其实是由于使用了同步消息造成的,高线程调度开销和程序列化的网络堆栈自身其实没有关系。在发现了根本原因之后,我们就将同步消息改为异步消息,异步消息同时大大提高了整个网络通路的pipeling效果。

 6、 主持人:DragonflyBSD是如何划分网络数据的?

 乔:我们根据源和目标IP地址和TCP的端口对接收到的数据包及套接字算出哈希值。根据运算出的哈希值,Dragonfly给接收到的数据包或套接字分配一个CPU专属的网络线程。

在2003年,Dragonfly使用线程来序列化网络堆栈,在那时我们使用一种非常简单的哈希函数,哈希运算完全由软件完成。从2009年开始,我们开始尝试使用网络硬件设备提供的哈希运算功能。该哈希运算功能是“receive side scaling”(RSS)的一部份。网络硬件设备会对接收到的数据包运算出一个哈希值,Dragonfly直接使用该哈希值。这样就减少了Dragonfly的哈希运算负担,并且避免了处理网络硬件中断的CPU和网络协议处理的CPU之间的缓存干扰。Dragonfly只对TCP和UDP的套接字进行哈希运算。

  Dragonfly使用两个字节来生成RSS键,这样生成的RSS哈希对于源目标IP地址和TCP端口是对称的。这一点对于Dragonfly非常关键,因为Dragonfly要求一个TCP连接的数据接收和发送必须在同一个CPU专属网络线程中处理。

 7、 主持人:Dragonfly还有其他特色和网络功能吗?

 乔:我们实现了很多TCP相关的RFC,有些RFC应该只有Dragonfly实现了。比如说,Eifel侦测和相应算法,该算法避免了不必要的TCP数据丢失恢复处理。还有early retransmit,limitted transmit和基于SACK的TCP数据丢失恢复处理。基于SACK的TCP数据丢失恢复处理性能还是非常不错的。再比如,TCP non-congestion robustness,该RFC避免了由于乱序TCP数据造成的不必要的TCP快速恢复处理。

我们改进了从FreeBSD继承而来的网络轮询功能,增加了现代网络设备多I/O队列的支持。我们从FreeBSD继承来的网络轮询只会轮询网络设备,主要是因为在网络轮询被实现的时候,还没有网络设备支持多I/O队列。因为现代网络设备的I/O队列可以完全独立操作,CPU专属网络线程可以在不争夺硬件资源的情况下轮询分配给他们的I/O队列。这样Dragonfly就可以充分利用现代网络设备多I/O队列并且享受网络轮询带来的各种好处,比如,限制CPU花在网络处理上的时间来避免网络DOS攻击带来的危害。

Matthew Dillon实现的fairq数据包调度在你需要网络数据优先级控制和带宽控制时非常有用。

我们还实现了一个针对SO_REUSEPORT的扩展。该扩展是由Google最早提交给Linux的。该扩展解决了下面描述的问题:

一个常规的TCP服务器通常使用一个监听套接字来接受新的TCP连接请求,这个监听套接字通常会被多个进程或线程共享。但是这种共享导致了两个问题。一个是TCP连接接受队列的竞争,另外一个是不均匀的套接字分布。

SO_REUSEPORT的扩展允许多个进程或线程在同一个IP地址和端口上各自创建独立的监听套接字,这样就完全避免了TCP连接接受队列的竞争。于此同时Dragonfly使用划分网络数据所使用的哈希函数将接受到的TCP连接分配到不同的SO_REUSEPORT监听套接字上,这样也解决了不均匀套接字分布的问题。

我们在dports系统中给nginx打了补丁来使用SO_REUSEPORT的扩展,这个补丁让nginx在Dragonfly上得到了极大的性能提升。最近nginx接受了我们的补丁并在nginx 1.9.1里支持SO_REUSEPORT的扩展。

最近一段时间,我们整合了Bill Yuan开发的IPFW3。IPFW3将IPFW进行了模块化,方便了日后的扩展。

除了Dragonfly的网络堆栈外,HAMMER文件系统是Dragonfly的一大特色。它可以自动镜像,恢复意外被删除的文件,对文件系统进行快照等等。

  还有就是SWAPCACHE,SWAPCACHE使用SSD作为交换空间,可以缓存文件系统的元数据,甚至文件数据。SWAPCACHE是一个通用实现,不依赖于所使用的文件系统。当你的文件系统是建立在硬盘上的时候,他可以极大的提高文件系统的性能,尤其是文件系统读的性能。

8、 主持人:能告诉我们一下Dragonfly的大概网络性能吗?

 乔:以下数据是我在开发相关系统时测量的,很多测量结果可能比当时要更好了。

  IPv4的路由性能:在有4个千兆网卡的计算机上,我们能做到在输入和输出上各5mpps。这个结果和理论值已经非常接近了。

  TCP数据传输的性能:我们能做到接收端和发送端各18Gbps。测试系统有两个万兆接口。

  TCP连接和关闭速率:在有一个万兆接口的计算机上。在使用SO_REUSEPORT扩展后,我们可以做到38万连接/秒,如果不使用SO_REUSEPORT扩展的话,我们大概在10万连接/秒。SO_REUSEPORT扩展给我们带来的性能改善显而易见。

  UDP请求和回应的速度:在有一个万兆接口的计算机上。我们可以做到139万交互/秒。

  最后nginx httperf的结果:我们大概可以处理4.9万请求/秒。Dragonfly可以处理更多请求因为在测试服务器上还有很多空闲时间。但是在测试的时候,我找不到更多的计算机来运行httperf了。

 9、 主持人:Dragonfly和其他BSD之间是否有很多代码交互吗?

 乔:是的,当然。我们的TSO实现参考了NetBSD的TSO实现。我们移植了OpenBSD的PF和CARP,FreeBSD的无线堆栈。很多网络设备的驱动是从其他BSD移植过来对的,Dragonfly的一些网络设备驱动也被移植到其他BSD上。

 10、              主持人:在我们结束之前还有其他的需要提一下的吗?

 乔:请关注HAMMER2文件系统。Matthew Dillon正在对其进行开发。一旦HAMMER2开发完成,它将成为Dragonfly最有吸引力的特色!

 原文:http://www.bsdnow.tv/episodes/2015_06_17-stacked_in_our_favor


DragonflyBSD微信公众号:BSDchina或BSD操作系统

邮箱:seallyhs@dragonflybsd.org

加载中
0
I
Imbrius

对协议栈的介绍让人受益匪浅.

希望能再多介绍一下dfbsd的内核,比如lwkt,无锁机制,hammer2等等.

0
dragonflyseallyhs
dragonflyseallyhs

引用来自“Imbrius”的评论

对协议栈的介绍让人受益匪浅.

希望能再多介绍一下dfbsd的内核,比如lwkt,无锁机制,hammer2等等.

和DragonflyBSD的commiter沟通了下,后续会写一下相关内容,可以关注DragonflyBSD的微信号哦(BSDchina)
0
I
Imbrius

引用来自“Imbrius”的评论

对协议栈的介绍让人受益匪浅.

希望能再多介绍一下dfbsd的内核,比如lwkt,无锁机制,hammer2等等.

引用来自“dragonflyseallyhs”的评论

和DragonflyBSD的commiter沟通了下,后续会写一下相关内容,可以关注DragonflyBSD的微信号哦(BSDchina)

多谢。*BSD 中,在下现在对 DragonflyBSD 最感兴趣。可是苦于资料比较少。

也希望自己将来能对DFBSD做出贡献。

0
dragonflyseallyhs
dragonflyseallyhs

引用来自“Imbrius”的评论

对协议栈的介绍让人受益匪浅.

希望能再多介绍一下dfbsd的内核,比如lwkt,无锁机制,hammer2等等.

引用来自“dragonflyseallyhs”的评论

和DragonflyBSD的commiter沟通了下,后续会写一下相关内容,可以关注DragonflyBSD的微信号哦(BSDchina)

引用来自“Imbrius”的评论

多谢。*BSD 中,在下现在对 DragonflyBSD 最感兴趣。可是苦于资料比较少。

也希望自己将来能对DFBSD做出贡献。

DragonflyBSD最近发布了个小任务:

DragonFlyBSD上编写驱动支持Collaborative Processor Performance Control

有兴趣的话可以弄一下,实现驱动的过程中有问题要讨论或者代码上传可以发到:kernel@dragonflybsd.org(邮件列表)

任务的具体描述可以参看微信号,或者见社区链接:http://www.oschina.net/question/2396255_245833

返回顶部
顶部