[ovs-dev] 答复: [PATCH v6] Use TPACKET_V3 to accelerate veth for userspace datapath

Ilya Maximets i.maximets at ovn.org
Fri Mar 13 16:47:54 UTC 2020

On 3/13/20 5:22 PM, William Tu wrote:
> On Fri, Mar 13, 2020 at 8:57 AM Ben Pfaff <blp at 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?

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.

More information about the dev mailing list