[ovs-dev] [PATCH v2] netdev-afxdp: Best-effort configuration of XDP mode.

William Tu u9012063 at gmail.com
Fri Nov 8 13:56:22 UTC 2019


On Thu, Nov 07, 2019 at 02:28:18PM +0100, Eelco Chaudron wrote:
> 
> 
> On 7 Nov 2019, at 14:21, Ilya Maximets wrote:
> 
> >On 07.11.2019 13:39, Eelco Chaudron wrote:
> >>
> >>
> >>On 7 Nov 2019, at 12:36, Ilya Maximets wrote:
> >>
> >>>Until now there was only two options for XDP mode in OVS: SKB or DRV.
> >>>i.e. 'generic XDP' or 'native XDP with zero-copy enabled'.
> >>>
> >>>Devices like 'veth' interfaces in Linux supports native XDP, but
> >>>doesn't support zero-copy mode.  This case can not be covered by
> >>>existing API and we have to use slower generic XDP for such devices.
> >>>There are few more issues, e.g. TCP is not supported in generic XDP
> >>>mode for veth interfaces due to kernel limitations, however it is
> >>>supported in native mode.
> >>>
> >>>This change introduces ability to use native XDP without zero-copy
> >>>along with best-effort configuration option that enabled by default.
> >>>In best-effort case OVS will sequentially try different modes starting
> >>>from the fastest one and will choose the first acceptable for current
> >>>interface.  This will guarantee the best possible performance.
> >>>
> >>>If user will want to choose specific mode, it's still possible by
> >>>setting the 'options:xdp-mode'.
> >>>
> >>>This change additionally changes the API by renaming the configuration
> >>>knob from 'xdpmode' to 'xdp-mode' and also renaming the modes
> >>>themselves to be more user-friendly.
> >>>
> >>>The full list of currently supported modes:
> >>>  * native-with-zerocopy - former DRV
> >>>  * native               - new one, DRV without zero-copy
> >>>  * generic              - former SKB
> >>>  * best-effort          - new one, chooses the best available from
> >>>                           3 above modes
> >>>
> >>>Since 'best-effort' is a default mode, users will not need to
> >>>explicitely set 'xdp-mode' in most cases.
> >>>
> >>>TCP related tests enabled back in system afxdp testsuite, because
> >>>'best-effort' will choose 'native' mode for veth interfaces
> >>>and this mode has no issues with TCP.
> >>>
> >>>Signed-off-by: Ilya Maximets <i.maximets at ovn.org>
> >>
> >>No review, I was running some performance tests for the OVS conference
> >>presentation so quickly tried this patch (assuming performance would
> >>increase :)…
> >>
> >>So with the native option (default for tap) I see a decrease, :(,  in
> >>performance over the skb mode (this is with my usual ovs_perf PVP test
> >>setup).
> >>
> >>With the patch applied, and default configuration
> >>(xdp-mode-in-use=native-with-zerocopy for my tap):
> >
> >Hmm. tap supports zero-copy? Interesting.

No, tap doesn't support zero-copy mode.

> >Have you tried forcing 'native' mode without zero-copy?
> >Maybe it will make sense to enable/disable need-wakeup feature.
> 
> Oops, wrong cut/paste: xdp-mode-in-use=native
> 
> All my the tests where with use-need-wakeup=true
> 
>   port 2: tapVM (afxdp: n_rxq=1, use-need-wakeup=true, xdp-mode=best-effort,
> xdp-mode-in-use=native)
> 
> >
> >>
> >>"Physical to Virtual to Physical test, L3 flows[port redirect]"
> >>,                 Packet size
> >>Number of flows,  64
> >>    1,             711581
> >>  100,             673152
> >>1000,             617733
> >>
> >>Here you will even see a performance drop with multiple IP flows (this
> >>is a single queue config).
> >
> >This is strange..

One explanation might be that
For using tap with native mode, OVS is sending XDP frame into the
kernel, but since tap device eventually has to create an skb and
forward to vhost_net then QEMU, so anyway we are having skb overhead.

On the other hand
For using tap with skb mode, there might be more optimization exist
in kernel, some batch allocation and batch rx/tx (See driver/net/tun.c)

--William


More information about the dev mailing list