[ovs-dev] 答复: [PATCH] Use TPACKET_V1/V2/V3 to accelerate veth for DPDK datapath

=?gb2312?B?WWkgWWFuZyAo0e6gRCkt1Ma3/s7xvK/NxQ==?= yangyi01 at inspur.com
Wed Jan 22 12:24:30 UTC 2020

Ben, thank you so much for your quick comments, yes, using some code to
check TPACKET features will be better, but I'm not familiar with AC_CHECK*
stuff, it will be better if you can show me a good example for reference,
I'll fix the issues you mentioned in next version. BTW, I'm taking Chinese
New Year long holiday, so next version post will be sent out after one week
at least. Welcome more comments from other folks.

·¢¼þÈË: Ben Pfaff [mailto:blp at ovn.org] 
·¢ËÍʱ¼ä: 2020Äê1ÔÂ22ÈÕ 3:26
ÊÕ¼þÈË: yang_y_yi at 163.com
³­ËÍ: ovs-dev at openvswitch.org; ian.stokes at intel.com; Yi Yang (Ñî D)-ÔÆ·þÎñ¼¯
ÍÅ <yangyi01 at inspur.com>
Ö÷Ìâ: Re: [PATCH] Use TPACKET_V1/V2/V3 to accelerate veth for DPDK datapath

On Tue, Jan 21, 2020 at 02:49:47AM -0500, yang_y_yi at 163.com wrote:
> From: Yi Yang <yangyi01 at inspur.com>
> We can avoid high system call overhead by using TPACKET_V1/V2/V3 and 
> use DPDK-like poll to receive and send packets (Note: send still needs 
> to call sendto to trigger final packet transmission).
> I can see about 30% improvement compared to last recvmmsg optimization 
> if I use TPACKET_V3. TPACKET_V1/V2 is worse than TPACKET_V3, but it 
> still can improve about 20%.
> For veth, it is 1.47 Gbps before this patch, it is about 1.98 Gbps 
> after applied this patch. But it is about 4.00 Gbps if we use 
> af_packet for veth, the bottle neck lies in ovs-vswitchd thread, it 
> will handle too many things for every loop (as below) , so it can't 
> work very efficintly as pmd_thread.
>         memory_run();
>         bridge_run();
>         unixctl_server_run(unixctl);
>         netdev_run();
>         memory_wait();
>         bridge_wait();
>         unixctl_server_wait(unixctl);
>         netdev_wait();
>         poll_block();
> In the next step, it will be better if let pmd_thread to handle tap 
> and veth interface.
> Signed-off-by: Yi Yang <yangyi01 at inspur.com>
> Co-authored-by: William Tu <u9012063 at gmail.com>
> Signed-off-by: William Tu <u9012063 at gmail.com>

Thanks for the patch!

I am a bit concerned about version compatibility issues here.  There are two
relevant kinds of versions.  The first is the version of the kernel/library
headers.  This patch works pretty hard to adapt to the headers that are
available at compile time, only dealing with the versions of the protocols
that are available from the headers.  This approach is sometimes fine, but
an approach can be better is to simply declare the structures or constants
that the headers lack.  This is often pretty easy for Linux data structures.
OVS does this for some structures that it cares about with the headers in
This approach has two advantages: the OVS code (outside these special
declarations) doesn't have to care whether particular structures are
declared, because they are always declared, and the OVS build always
supports a particular feature regardless of the headers of the system on
which it was built.

The second kind of version is the version of the system that OVS runs on.
Unless a given feature is one that is supported by every version that OVS
cares about, OVS needs to test at runtime whether the feature is supported
and, if not, fall back to the older feature.  I don't see that in this code.
Instead, it looks to me like it assumes that if the feature was available at
build time, then it is available at runtime.
This is not a good way to do things, since we want people to be able to get
builds from distributors such as Red Hat or Debian and then run those builds
on a diverse collection of kernels.

One specific comment I have here is that, in acinclude.m4, it would be
The latter is for testing for kernel builds only; we can't use the normal
AC_* tests for those because we often can't successfully build kernel
headers using the compiler and flags that Autoconf sets up for building OVS.



More information about the dev mailing list