Io_uring is a feature brought in by Linux kernel 5.1, so it can't be used on Linux system with kernel version < 5.1. tpacket_v3 is only one way to avoid system call on almost all the Linux kernel versions, it is unique from this perspective. Maybe you will miss it if someone fixes kernel side issue :-)
In addition, according to what Flavio said, TSO can't support VXLAN currently, but in most cloud scenarios, VXLAN is only one choice, so for such cases, TSO can be ignored. My point is we can provide one option for such use cases, once kernel side issue is fixed, all the Linux distributions can apply this fix, users can get immediate benefits without change. So maybe adding a switch userspace-use-tpacket-v3 in other-config (set to False by default) is an acceptable way to handle this. -----邮件原件----- 发件人: dev [mailto:[email protected]] 代表 Ilya Maximets 发送时间: 2020年3月14日 0:48 收件人: William Tu <[email protected]>; Ben Pfaff <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [ovs-dev] 答复: [PATCH v6] Use TPACKET_V3 to accelerate veth for userspace datapath On 3/13/20 5:22 PM, William Tu wrote: > On Fri, Mar 13, 2020 at 8:57 AM Ben Pfaff <[email protected]> wrote: >> >> On Fri, Mar 13, 2020 at 01:04:07AM +0000, Yi Yang (杨燚)-云服务集团 wrote: >>> Per my understanding, Ben meant a build system (which isn't Linux >>> probably, it doesn't have include/linux/if_packet.h) should be able >>> to build tpacket_v3 code in order that built-out binary can work on >>> Linux system with tpacket_v3 feature, this is Ben's point, that is >>> why he wanted me to add include/linux/if_packet.h in ovs repo. >>> >>> Ben, can you help double confirm if include/linux/if_packet.h in ovs >>> is necessary? >> >> I think my meaning was misunderstood. Linux always has if_packet.h. >> Only recent enough Linux has TPACKET_V3 in if_packet.h. If the >> system is Linux but the TPACKET_V3 types and constants are not >> defined in if_packet.h, then the build system should define them. > > Thanks! > > My suggestion is that if the system is Linux but the TPACKET_V3 types > and constants are not defined in if_packet.h, then just skip using > TPACKET_V3 and > use the current recvmmsg approach. Because when we start TPACKET_V3 > patch, the af_packet on veth performance is about 200Mbps, so > tpacket_v3 has huge performance benefits. > > With YiYang's patch > "Use batch process recv for tap and raw socket in netdev datapath" > the af_packet on veth improves to 1.47Gbps. And tpacket_v3 shows > similar or 7% better performance. So there isn't a huge benefits now. With such a small performance benefit does it make sense to have these 700 lines of code that is so hard to read and maintain? Another point is that hopefully segmentation offloading in userspace datapath will evolve so we could enable it by default and all this code will become almost useless. If you're looking for poll mode/async -like solutions we could try and check io_uring way for calling same recvmsg/sendmsg. That might have more benefits and it will support all the functionality supported by these calls. Even better, we could also make io_uring support as an internal library and reuse it for other OVS subsystems like making async poll/timers/logging/etc in the future. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
