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

William Tu u9012063 at gmail.com
Fri Mar 13 17:04:16 UTC 2020


On Fri, Mar 13, 2020 at 9:48 AM Ilya Maximets <i.maximets at ovn.org> wrote:
>
> 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?

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


More information about the dev mailing list