Chinaunix

标题: Xen虚拟化+万兆网卡环境，DomU网络性能问题 [打印本页]
作者: humjb_1983    时间: 2013-11-19 12:34
标题: Xen虚拟化+万兆网卡环境，DomU网络性能问题
最近在弄Xen虚拟化环境中，万兆网卡的性能问题，实测DomU中的网络性能只能到2G+，无论如何调优，也无法达到限速，不知哪位大侠有相关优化和测试经验，学习交流下~，感谢！
作者: lenky0401    时间: 2013-11-19 16:23
用到了网卡的硬件虚拟化吧？
作者: humjb_1983    时间: 2013-11-20 08:57
lenky0401 发表于 2013-11-19 16:23
用到了网卡的硬件虚拟化吧？

么有，用的半虚拟化驱动，由于SR-IOV会影响虚拟机迁移，所以无法用~~
作者: almeydifer    时间: 2013-11-21 11:47
Dom U是何谁通信呀？它也在同一台物理机器上吗？
作者: humjb_1983    时间: 2013-11-21 12:27
almeydifer 发表于 2013-11-21 11:47
Dom U是何谁通信呀？它也在同一台物理机器上吗？

是的，同一台物理机上的dom0和domu
作者: humjb_1983    时间: 2013-11-21 14:56
almeydifer 发表于 2013-11-21 11:47
Dom U是何谁通信呀？它也在同一台物理机器上吗？

不好意思，刚才写错了，应该是不用物理主机间的domU，通过万兆网卡通讯。
作者: almeydifer    时间: 2013-11-22 15:40
回复 6# humjb_1983

都是多核的服务器吗？

试试把每台机器的Dom0和DomU都绑定在同一个物理CPU上（或者接近的）。
意思就是尽量让Dom0和DomU可以共享L2/L3的缓存。




   
作者: humjb_1983    时间: 2013-11-22 16:16
almeydifer 发表于 2013-11-22 15:40
回复 6# humjb_1983

都是多核的服务器吗？

呵呵，这个已经试过了，效果甚微，分析瓶颈应该还在半虚拟化驱动这块，目前还没想到好的优化措施，因为离限速的目标还太遥远。
作者: crspo    时间: 2013-11-22 16:20
回复 8# humjb_1983


    物理网卡的GRO打开了吗，netback的GSO打开了吗
作者: humjb_1983    时间: 2013-11-22 17:49
crspo 发表于 2013-11-22 16:20
回复 8# humjb_1983

物理网卡的GRO开了，netback的GSO不知如何确认？netback应该只是一个内核线程吧？呵呵
作者: almeydifer    时间: 2013-11-22 19:08
要不试试KVM吧。
作者: 瀚海书香    时间: 2013-11-23 10:05
回复 1# humjb_1983
PCIE网卡吧。是否将该PCI设备直接挂载到DomU上？

   
作者: almeydifer    时间: 2013-11-24 11:38
本帖最后由 almeydifer 于 2013-11-24 11:41 编辑

我印象当中Xen的网络性能已经不错了呀，你用的是啥版本的呢？

下面这篇论文看看有没有帮助。

https://www.usenix.org/conferenc ... sessions/papers/ram

作者: humjb_1983    时间: 2013-11-25 08:58
almeydifer 发表于 2013-11-22 19:08
要不试试KVM吧。

呵呵，目前基于xen开发，无法切换到kvm~
作者: humjb_1983    时间: 2013-11-25 08:59
瀚海书香 发表于 2013-11-23 10:05
回复 1# humjb_1983
PCIE网卡吧。是否将该PCI设备直接挂载到DomU上？

瀚海兄的意思是，网卡passthrough？SR-IOV？
作者: humjb_1983    时间: 2013-11-25 09:13
almeydifer 发表于 2013-11-24 11:38
我印象当中Xen的网络性能已经不错了呀，你用的是啥版本的呢？

下面这篇论文看看有没有帮助。

感谢，4.1版本，看了下文章，该文主要是针对虚拟机交换技术的优化，目前我们用的是ovs，经测试，从dom0经ovs到另一台主机的dom0，发现是能达到限速的，说明瓶颈并不在ovs上。目前分析瓶颈应该还在于前后端驱动，前后端驱动交互流程太复杂，而且没有实现多队列，难以达到万兆网卡的性能要求，但目前还未确认优化方案，难度比较大。
作者: 瀚海书香    时间: 2013-11-25 09:21
回复 15# humjb_1983


   
作者: humjb_1983    时间: 2013-11-25 09:41
回复 17# 瀚海书香
hh，这种方法(SR-IOV，VMDC)确实能大幅提高网络性能，但是如果采用这种方法，就无法进行虚拟机迁移，因为与硬件环境强相关，所以我们目前无法考虑使用~~


   
作者: hmsghnh    时间: 2013-11-25 10:52
:wink:我是来围观的，楼主能不能不停的更新详细的测试步骤和进展哈
让大家都看一下
作者: hmsghnh    时间: 2013-11-25 10:58
humjb_1983 发表于 2013-11-25 09:13
感谢，4.1版本，看了下文章，该文主要是针对虚拟机交换技术的优化，目前我们用的是ovs，经测试，从dom0经 ...



你这个同样经过前端驱动那些吧。
作者: crspo    时间: 2013-11-25 11:22
humjb_1983 发表于 2013-11-22 17:49
物理网卡的GRO开了，netback的GSO不知如何确认？netback应该只是一个内核线程吧？呵呵


ethtool -k $vif.X ?
作者: humjb_1983    时间: 2013-11-25 11:45
crspo 发表于 2013-11-25 11:22
ethtool -k $vif.X ?

哦，这个是开了的~~
作者: humjb_1983    时间: 2013-11-25 11:49
hmsghnh 发表于 2013-11-25 10:58
你这个同样经过前端驱动那些吧。

dom0到另一个dom0，不经过前后端驱动，只有dumU和domU/0通信的时候需要经过~
作者: humjb_1983    时间: 2013-11-25 11:50
hmsghnh 发表于 2013-11-25 10:52
我是来围观的，楼主能不能不停的更新详细的测试步骤和进展哈
让大家都看一下

呵呵，可以的，但进展比较慢，只能后面慢慢搞了，估计周期比较长~
作者: almeydifer    时间: 2013-11-25 12:35
这个问题是很有趣，如果通过配置解决了问题，楼主一定要告知我们一声呀。

我的意见是：看看能不能通过类似oprofile等工具对测试流程进行一个收集与分析，看看瓶颈哪里了？

我记得早些年Xen的前后段驱动有瓶颈，主要是因为共享内存的频繁分配和回收造成到开销（动态），但是这些年Xen的社区一直在改进网络前后端的共享内存分配方式（静态），这个开销已经较小了（包括一些多队列的优化）。

而且我记得有篇论文，也是在万兆网卡下的性能调优，方法较为复杂，但是效果很好.
http://www.hpl.hp.com/techreports/2009/HPL-2009-25.html

最近几年，大家都去研究passthrough的网卡硬件中断优化了，前后端的进一步优化都几乎停滞了，不知到是不是优化空间已经小了。
作者: humjb_1983    时间: 2013-11-25 12:57
almeydifer 发表于 2013-11-25 12:35
这个问题是很有趣，如果通过配置解决了问题，楼主一定要告知我们一声呀。

我的意见是：看看能不能通过类 ...

almeydifer很专业哦~
这个问题通过配置肯定搞不定，各种配置我们都试过了，都是不行的。
你说的xen前后端共享内存优化确实有，应该是指静态授权页表吧，这个东东也打算试~~
你说的“多队列”这个应该目前还没有完全实现吧？查找了前后端多队列的相关补丁，目前一些前置补丁已合入，但主要功能还只是列在了xen计划实现的列表中，何时能有现成的补丁尚未可知（也许遥遥无期~），兄弟如果有相关经验，我们也可以探讨探讨哈~~
另外，你说的HP的文档，能提到这个，说明almeydifer之前应该是有过类似经验的~~，这个也正是我们后续优化方向，目前正在摸索中，HP的实现很复杂，改动也很大，除了这个论文外也没找到其他资料，如果兄弟有经验或建议，欢迎讨论。

作者: crspo    时间: 2013-11-25 16:24
humjb_1983 发表于 2013-11-25 11:45
哦，这个是开了的~~


是双方向都达不到线速，还是单向。

netfront最近支持GRO，你可以尝试一下。

btw，可以尝试一下KVM的virtio-net
作者: crspo    时间: 2013-11-25 16:25
回复 26# humjb_1983


    KVM/virtio-net已经支持多队列，欢迎测试。
作者: humjb_1983    时间: 2013-11-25 17:01
crspo 发表于 2013-11-25 16:24
是双方向都达不到线速，还是单向。

netfront最近支持GRO，你可以尝试一下。

双向都达不到，你说的netfront是指最新内核版本中带的前端驱动么？
作者: humjb_1983    时间: 2013-11-25 17:03
crspo 发表于 2013-11-25 16:25
回复 26# humjb_1983

感谢~，可惜我们目前没有切换kvm的计划，估计这个暂时无法测试了，如果哪位大侠测试过kvm中万兆网卡的性能，还望分享下~~
作者: crspo    时间: 2013-11-25 17:05
回复 29# humjb_1983


    对,    https://git.kernel.org/cgit/linu ... 066cb327dfb523d598e
    请问是性能是采用什么工具测试的
作者: crspo    时间: 2013-11-25 17:06
回复 30# humjb_1983


    10gb轻松达到线速，下个月测试一下40gbe.
作者: humjb_1983    时间: 2013-11-25 17:09
crspo 发表于 2013-11-25 17:05
回复 29# humjb_1983

netperf，链接我们慢慢研究下，感谢~~
作者: humjb_1983    时间: 2013-11-25 17:14
crspo 发表于 2013-11-25 17:06
回复 30# humjb_1983

哇塞~~，请问是domU之间吗？你们用什么工具？看来Xen的劣势越来越~~~，看来得多向crspo兄请教了~
作者: crspo    时间: 2013-11-25 17:44
回复 34# humjb_1983


    是测试另外一个主机通过10gbe网线到另外一端的主机上的guest. 也是netperf. Xen也应该能达到线速,至少在发大包的时候。你测试dom0能达到限速吗。netperf包大小是多少？tcpdump在DomU（接受端时)里面的平均包大小是多少?
作者: humjb_1983    时间: 2013-11-26 09:44
crspo 发表于 2013-11-25 17:44
回复 34# humjb_1983

两个Dom0之间是可以达到限速的，但是Dom0和DomU之间无论如何调优都无法超过3G。netperf各种包长都试过了~，通常采用mtu大小
在接收端(DomU)上统计包大小好像没有意义，因为硬件通常是开了LRO的，在接收端应该会进行组包，之前也没有统计过~
作者: humjb_1983    时间: 2013-11-26 10:17
crspo 发表于 2013-11-25 17:44
回复 34# humjb_1983

您是怀疑组包的问题？相关选项我们都试过了，tso/gso/gro/lro等，都没用~，您说的xen应该能达到限速不知是否有测过？据我们查阅的资料和测试情况，如果不做机制性的优化和改动，好像确实搞不定~~
感谢~~
作者: almeydifer    时间: 2013-11-26 14:33
回复 37# humjb_1983

说来惭愧，我几年前是研究过Xen的网络性能优化，后面发现搞的人太多，就搞块设备前后端去了。

后面由于跑到学术界去混了，所以重点都去写文忽悠去了，技术都有些荒废了。

不过像那位仁兄所说的，现在业余时间我也在搞KVM，感觉更加方便，社区也很强大。


   
作者: humjb_1983    时间: 2013-11-26 17:29
almeydifer 发表于 2013-11-26 14:33
回复 37# humjb_1983

说来惭愧，我几年前是研究过Xen的网络性能优化，后面发现搞的人太多，就搞块设备前 ...

呵呵，看来还得跟您多请教学习~，请问是否有“当前研究Xen网络性能优化”的一些资料或是经验、思路，还望分享下，目前我们非常需要~~，感谢感谢！
作者: 瀚海书香    时间: 2013-11-26 18:41
回复 39# humjb_1983
UP!

   
作者: crspo    时间: 2013-11-27 11:09
回复 36# humjb_1983


    主要是想看一下Dom0网卡驱动的GRO和netback的GSO是否工作正常。如果tcpdump出来的都是小包<MTU,证明可能工作不正常。
    另外硬件网卡的LRO应该关闭的，如果它被做为一个网桥的interface.
作者: humjb_1983    时间: 2013-11-27 12:40
crspo 发表于 2013-11-27 11:09
回复 36# humjb_1983

在接收端tcpdump抓包流程是在GRO组包前？还是组包后？如果是组包前，应该就看不出效果了吧？
之前我们在千兆环境中测试过GSO、GRO等特性，在大包情况下，效果甚微。
另外，看您比较确信Xen的性能能到限速，不知是否有相关经验或依据？能否分享下~~
作者: crspo    时间: 2013-11-27 12:58
humjb_1983 发表于 2013-11-27 12:40
在接收端tcpdump抓包流程是在GRO组包前？还是组包后？如果是组包前，应该就看不出效果了吧？
之前我们在 ...


可能没说清楚，先要排除offload的影响。因为没有GRO,guest很难达到限速。所以意思是当guest做为接受端时，在guest做tcpdump。通常收包的流程是，网卡收包->[1]Host GRO对包进行合并->转发至netback[2]->通过ring发送至netfront

在guest里面tcpdump能确保[1]和[2]不出现问题。
作者: crspo    时间: 2013-11-27 12:59
humjb_1983 发表于 2013-11-27 12:40
在接收端tcpdump抓包流程是在GRO组包前？还是组包后？如果是组包前，应该就看不出效果了吧？
之前我们在 ...


我很多年没用过Xen,只是凭经验。如果达不到线速，应该早就有人在list里面抱怨了。
作者: humjb_1983    时间: 2013-11-27 13:55
crspo 发表于 2013-11-27 12:58
可能没说清楚，先要排除offload的影响。因为没有GRO,guest很难达到限速。所以意思是当guest做为接受端时 ...

哦，明白，我们后面关注确认下，感谢！
作者: humjb_1983    时间: 2013-11-27 14:04
crspo 发表于 2013-11-27 12:59
我很多年没用过Xen,只是凭经验。如果达不到线速，应该早就有人在list里面抱怨了。

估计是万兆网卡还未普及，目前网上也有一些人反馈Xen确实达不到限速，能达到的都是做了架构性的优化，比如使用VMDC（SR-IOV）或是HP论文中说的基于VMDQ的优化方案(改动看似也非常大)，这两种思路，都基本绕过了前后端驱动，才能达到限速。
另外，请教下，KVM中，如果virtio-net不使用多队列，那能达到限速吗？我看官方的测试数据，多队列好像对性能提升不算太明显？virtio-net效率这么高的基本原理是啥？理论上virtio也需要经过host和guest的数据通信吧，其效率高在哪里？Xen中是否有移植virtio-net的可能？
作者: crspo    时间: 2013-11-27 14:29
回复 46# humjb_1983


    不用多队列可以达到线速。多队列对多个并行请求的延迟改进还是非常明显的，对于但对列多个vcpu，一个vhost thread很容易达到瓶颈。不过多队列面临一个一个问题是需要跟TCP/GSO更好的协作。目前的GSO假定应用程序会以非常快的速度填充发送缓冲区，这个假设在虚拟化环境，特别是多队列情况下不是非常的适用。也许未来会有一些优化。
    一点理解，virtio就设专门为虚拟化环境设计的，目的就是简化设计（所以前后端都非常简单）并且减少exit/irq的次数。一个简单的例子对比virtio-net和netfront，virito-net几乎不使用tx中断，目的就是减少irq/exit的次数提高性能。
作者: crspo    时间: 2013-11-27 14:31
如果使用官方的qemu,HVM里面应该可以使用virtio-net吧,毕竟只是一个PCI设备，vhost可能不行。
作者: crspo    时间: 2013-11-27 14:31
如果使用官方的qemu,HVM里面应该可以使用virtio-net吧,毕竟只是一个PCI设备，vhost可能不行。
作者: crspo    时间: 2013-11-27 14:31
华为好像正在搞HVM里面的virito-net/vhost支持。
作者: humjb_1983    时间: 2013-11-27 15:35
回复 50# crspo
感谢crspo大侠指点，这些信息对我们很有帮助！
刚搜了一把，真如crspo所说，xen中确实已经实现了对virtio的移植(包括HVM和PV)：
http://wiki.xen.org/wiki/Virtio_On_Xen
看来这条路很有希望~~
但不确认效果如何，如有大牛已做过相关移植工作和测试，望赐教~


   
作者: atkisc    时间: 2013-11-28 12:00
crspo 发表于 2013-11-22 16:20
回复 8# humjb_1983


你可以尝试先关了gso /tso
作者: humjb_1983    时间: 2013-11-28 14:24
atkisc 发表于 2013-11-28 12:00
你可以尝试先关了gso /tso

呵呵，为什么要这样？关了性能会降低吧~~
作者: atkisc    时间: 2013-11-28 14:27
humjb_1983 发表于 2013-11-28 14:24
呵呵，为什么要这样？关了性能会降低吧~~


我不知道你是否用了virtio?
作者: humjb_1983    时间: 2013-11-28 15:28
atkisc 发表于 2013-11-28 14:27
我不知道你是否用了virtio?

呵呵，还没，还在评估分析中~
作者: 瀚海书香    时间: 2013-11-29 10:02
Performance Analysis of Large Receive Offload in a Xen Virtualized System
http://web-ext.u-aizu.ac.jp/~hitoshi/RESEARCH/XenLRO_iccet.pdf
作者: crspo    时间: 2013-11-29 10:47
瀚海书香 发表于 2013-11-29 10:02
Performance Analysis of Large Receive Offload in a Xen Virtualized System
http://web-ext.u-ai ...


通篇没有提到GSO和GRO，这哥俩是目前使用的技术而不是LRO。
作者: humjb_1983    时间: 2013-11-29 11:08
瀚海书香 发表于 2013-11-29 10:02
Performance Analysis of Large Receive Offload in a Xen Virtualized System
http://web-ext.u-ai ...

感谢瀚海兄分享，这偏论文估计比较老了，说的是LRO特性，这个主要是硬件特性，内核中好像都不推荐使用了，取而代之的是GRO，更通用。论文结论说明LRO对性能是有提升的，说明GRO也应该有相应的作用，这个如之前crspo所说，pv驱动应该已经支持了，对性能应该有改善，但应该达不到限速。目前还没时间测，呵呵~
作者: hmsghnh    时间: 2013-11-29 13:15
Xen Network I/O
Performance Analysis and
Opportunities for Improvement
http://xen.xensource.com/files/xensummit_4/NetworkIO_Santos.pdf

这里数据很详细，即使说数据比较老，至少方法很不错。   我觉得至少楼主有条件，也按照这个，给我们弄个测试数据看看。:wink:   
相比较去怀疑这怀疑那，netback netfront之类的， 弄个完整的分析更有参考价值吧。
作者: 帅绝人寰    时间: 2013-11-29 14:42
What's your Xen backent?

can you post your "xenstore-ls" ?
作者: humjb_1983    时间: 2013-11-29 16:26
本帖最后由 humjb_1983 于 2013-11-29 16:57 编辑
帅绝人寰 发表于 2013-11-29 14:42
What's your Xen backent?

can you post your "xenstore-ls" ?

信息量有点大~，我这也不能上传附件，能否明确下具体需要哪些信息，我摘出来~~
tool = ""
xenstored = ""
vm = ""
00000000-0000-0000-0000-000000000000 = ""
  mg_key = ""
  dynmemmax = "2144600064"
  vcpu_avail = "65535"
  session_key = ""
  dynmemmin = "2144600064"
  uuid = "00000000-0000-0000-0000-000000000000"
  on_reboot = "restart"
  priority = "1"
  memory = "0"
  image = "(linux (kernel '') (superpages 0) (memory_sharing 0) (nomigrate 0\..."
   ostype = "linux"
   kernel = ""
   cmdline = ""
   ramdisk = ""
  on_xend_stop = "ignore"
  pool_name = "Pool-0"
  check_pv_state = "0"
  on_poweroff = "destroy"
  on_xend_start = "ignore"
  on_crash = "restart"
  xend = ""
...
  device = ""
   vkbd = ""
    0 = ""
     frontend = "/local/domain/2/device/vkbd/0"
     frontend-id = "2"
     backend-id = "0"
     backend = "/local/domain/0/backend/vkbd/2/0"
   vfb = ""
    0 = ""
     frontend = "/local/domain/2/device/vfb/0"
     frontend-id = "2"
     backend-id = "0"
     backend = "/local/domain/0/backend/vfb/2/0"
...
作者: humjb_1983    时间: 2013-11-29 17:04
hmsghnh 发表于 2013-11-29 13:15
Xen Network I/O
Performance Analysis and
Opportunities for Improvement

感谢指点~~，我们先看看，不过链接好像打不开哦~
作者: humjb_1983    时间: 2013-11-29 17:21
hmsghnh 发表于 2013-11-29 13:15
Xen Network I/O
Performance Analysis and
Opportunities for Improvement

看了一下，数据的确很详细，但其中的优化方法都涉及代码或架构的改动，而且只是简单提了一下，难以了解具体的实现方法，估计参考实现还比较麻烦~~，可用作后续的进一步优化参考，感谢hmsghnh的支持，如有其它资料或思路，也请一并砸一下，非常感谢！
作者: humjb_1983    时间: 2014-02-17 11:25
crspo 发表于 2013-11-25 17:06
回复 30# humjb_1983

请问crspo帅哥，40G的测试结果如何？说的40G是单网卡硬件支持的带宽？
作者: crspo    时间: 2014-02-17 12:54
humjb_1983 发表于 2014-02-17 11:25
请问crspo帅哥，40G的测试结果如何？说的40G是单网卡硬件支持的带宽？


单网卡，发包问题不大，基本有30多G，收包有点问题，初步推测可能是单个vcpu不足以处理这么多的流量。暂时没有时间继续分析，增大rsc可能能达到限速。

过几天有时间在看看：）
作者: humjb_1983    时间: 2014-02-17 14:32
crspo 发表于 2014-02-17 12:54
单网卡，发包问题不大，基本有30多G，收包有点问题，初步推测可能是单个vcpu不足以处理这么多的流量。暂 ...

呵呵，接收和发送还不一样？请问你的测试模型具体是怎样的？是测试的domU和domU之间的性能么？
作者: crspo    时间: 2014-02-17 16:05
回复 66# humjb_1983


    就是测试Guest到一个外部的Host.
作者: humjb_1983    时间: 2014-02-17 16:49
crspo 发表于 2014-02-17 16:05
就是测试Guest到一个外部的Host.

哦，测试过两台主机domU之间的性能么？目前发送和接收分别能达到多少?
作者: crspo    时间: 2014-02-17 17:10
humjb_1983 发表于 2014-02-17 16:49
哦，测试过两台主机domU之间的性能么？目前发送和接收分别能达到多少?


发包大概34Gbit/s，收包大概29Gbit/s。增加物理网卡的rsc应该可以再提升性能。
作者: humjb_1983    时间: 2014-02-17 17:22
本帖最后由 humjb_1983 于 2014-02-17 17:22 编辑
crspo 发表于 2014-02-17 17:10
发包大概34Gbit/s，收包大概29Gbit/s。增加物理网卡的rsc应该可以再提升性能。

呵呵，domu之间的性能是否有测？测试包长是多少？rsc是啥？谢谢！
作者: gaojl0728    时间: 2014-02-17 17:54
回复 1# humjb_1983


我们以前测过 NAPI和none-NAPI(传统的只通过中断收包)的网卡驱动性能，

NAPI 到10G没问题。
none-NAPI只能到5G+, 再多了内核就会卡死。


你能确定网卡驱动已经是NAPI了吗？
作者: crspo    时间: 2014-02-17 19:17
humjb_1983 发表于 2014-02-17 17:22
呵呵，domu之间的性能是否有测？测试包长是多少？rsc是啥？谢谢！


没测，包长度是netperf默认长度，GSO后实际发包大小是64K，收包不一定，大部分也大于40K，rsc是mlx4默认设置
作者: humjb_1983    时间: 2014-02-18 08:19
gaojl0728 发表于 2014-02-17 17:54
回复 1# humjb_1983

napi肯定开了，这个是xen虚拟化环境，如果是物理机，达到限速是没有问题的，
瓶颈应该在于虚拟化pv驱动或其它地方，目前还不完全确认。
作者: humjb_1983    时间: 2014-02-18 08:25
crspo 发表于 2014-02-17 19:17
没测，包长度是netperf默认长度，GSO后实际发包大小是64K，收包不一定，大部分也大于40K，rsc是mlx4默认 ...

你的物理网卡的mtu设为多少？64K也能发出去？虚拟网卡的mtu多少？这里的GSO指的是虚拟网卡还是物理网卡的属性？
作者: crspo    时间: 2014-02-18 09:07
humjb_1983 发表于 2014-02-18 08:25
你的物理网卡的mtu设为多少？64K也能发出去？虚拟网卡的mtu多少？这里的GSO指的是虚拟网卡还是物理网卡的 ...


物理网卡1500，GSO是指虚拟机发出的包大小，由于mlx4支持TSO，所以也是最终传递给mlx4的包大小。虚拟网卡mtu1500.
作者: humjb_1983    时间: 2014-02-18 10:05
crspo 发表于 2014-02-18 09:07
物理网卡1500，GSO是指虚拟机发出的包大小，由于mlx4支持TSO，所以也是最终传递给mlx4的包大小。虚拟网 ...

昨天搭了个kvm+virtio+万兆网卡的环境，测试domu-》domu之间的性能只有800M，还不如xen，不知道是哪里没整对，
还请兄弟指教，看看有哪些关键点需要注意？有相关资料就更好了？呵呵
作者: humjb_1983    时间: 2014-02-18 10:13
crspo 发表于 2014-02-18 09:07
物理网卡1500，GSO是指虚拟机发出的包大小，由于mlx4支持TSO，所以也是最终传递给mlx4的包大小。虚拟网 ...

你的虚拟网卡mtu为1500，那么virtio前后端通信的时候不会将数据包分片么？最终到网卡的包还会有64K？
作者: crspo    时间: 2014-02-18 10:44
回复 77# humjb_1983


    当host支持GSO的时候猴，viritio-net会announce自己支持TSO/GSO，这样driver就可以直接传大包给virtio-net。而virito-net则直接将大包传递给host,什么都不做
作者: humjb_1983    时间: 2014-02-18 11:18
本帖最后由 humjb_1983 于 2014-02-18 11:28 编辑
crspo 发表于 2014-02-18 10:44
回复 77# humjb_1983

是的，把虚拟网卡gso开启后，性能从800M提升到1.3G了(512的包)，64k包性能在2G左右，但是离目标还是差很远，不知还有哪里需要特别设置？
请问，你测试过512的包么？
说明，目前我们测的是windows domU之间的性能。难道Linux的表现差别会很大？
另外，我们目前测试两台dom0之间的性能都能难达到限速，小包只有3-4G，大包也在6-8G之间，经过绑核和其他参数调整后，大包能勉强达到9G，
如果dom0之间都无法达到限制，domU之间就不可能了吧，不知你的测试模型中，dom0侧是否做过优化？比如绑核之类的，你的domU的vcpu个数
是多少？
作者: crspo    时间: 2014-02-18 14:25
回复 79# humjb_1983

没有测试过512的包，只测试过Linux的Guest. 印象中Windows的Guest需要一些调优参数，具体忘记了。

Dom0之前不能到线速证明环境和配置有问题，需要先把Dom0达到线速才可以。

对于10gbe(ixgbe)网卡，不需要任何的配置就可以到线速。

对于40gbe(mlx4)，Guest发包要使用sendpage()+zerocopy vhost。pin一下vhost和vcpu thread即可。
作者: humjb_1983    时间: 2014-02-18 16:59
crspo 发表于 2014-02-18 14:25
回复 79# humjb_1983

没有测试过512的包，只测试过Linux的Guest. 印象中Windows的Guest需要一些调优参数 ...

感谢，继续问问
10G网卡，不绑核，不做调优，dom0之间能直接达到限速？你的dom0用的什么版本的OS呢？
另外，windows的中调优参数能否帮忙找找，windows这个黑盒目前我们各种方法都用尽了，实在搞不定，linux要好弄多了~~
感谢crspo兄弟的支持！
作者: crspo    时间: 2014-02-18 17:58
humjb_1983 发表于 2014-02-18 16:59
感谢，继续问问
10G网卡，不绑核，不做调优，dom0之间能直接达到限速？你的dom0用的什么版本的OS呢？
另 ...


印象中只要没有bug,从3.0到现在(3.14)达到10g线速很容易。

Windows的有一个wiki，可以参考一下，不知到起不起作用：
http://www.linux-kvm.org/page/WindowsGuestDrivers/kvmnet/registry
作者: crspo    时间: 2014-02-18 17:59
另外有个小更正，因为是KVM所以不是Dom0而就是Host
作者: humjb_1983    时间: 2014-02-19 08:29
crspo 发表于 2014-02-18 17:58
印象中只要没有bug,从3.0到现在(3.14)达到10g线速很容易。

Windows的有一个wiki，可以参考一下，不知 ...

感谢，先看看~~
另外，host之间要达到限速，应该是硬件和配置有关吧？不知你测试时用的机器的配置如何？几核？主频？
测试domU的性能时，给domU分了几个vcpu？
作者: crspo    时间: 2014-02-19 11:31
lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 44
Model name:            Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
Stepping:              2
CPU MHz:               2395.000
BogoMIPS:              4787.78
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              12288K
NUMA node0 CPU(s):     0-3
NUMA node1 CPU(s):     4-7

lspci | grep 8259
0f:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
0f:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

guest 1 个vcpu就可以达到限速，不需要任何的配置。

你的10gb卡是什么？
作者: humjb_1983    时间: 2014-02-19 12:46
crspo 发表于 2014-02-19 11:31
lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit

呵呵，感谢，我们用的intel 82599的万兆网卡，其他的好像也有~
目前我们新搭建的redhat6的kvm host主机之间的大包性能仅为6G，小包3G，domU之间(virio)大包只有2G，
小包只有1.5G，gso开了，其他参数未做调整，跟你的结果差距比较大，不知还有啥关键的东西没有考虑到？
还望指点。谢谢！
作者: crspo    时间: 2014-02-19 13:06
回复 86# humjb_1983


    寻求RH的技术支持吧
作者: humjb_1983    时间: 2014-02-19 13:55
crspo 发表于 2014-02-19 13:06
回复 86# humjb_1983

呵呵，这个暂时不考虑了，我们再继续捯饬捯饬~~，感谢兄弟的指点和支持。



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2