On Fri, Mar 13, 2020 at 9:48 AM Ilya Maximets <i.maxim...@ovn.org> wrote: > > On 3/13/20 5:22 PM, William Tu wrote: > > On Fri, Mar 13, 2020 at 8:57 AM Ben Pfaff <b...@ovn.org> 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?
Agree. I was hoping that using "tpacket_v3 + is_pmd=true + TSO" can show much better performance. But TSO has some issue and this patch is not there yet. > > 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. Thanks! I will take a look. William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
