On Thu, Nov 07, 2019 at 01:39:28PM +0100, 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.maxim...@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):
> 
> "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).
> 
> With SKB mode (xdp-mode-in-use=generic):
> 
> "Physical to Virtual to Physical test, L3 flows[port redirect]"
> ,                 Packet size
> Number of flows,  64
>    1,             800796
>  100,             800912
> 1000,             800133
> 

Hi Eelco,

I have another question (not directly related to this patch).

When doing PVP testing, what's the total CPU consumption?
I'm trying to think about the efficiency, ex:
  Packet forwarding rate / CPU utilization

For native-with-zerocopy, is it correct that your system uses
  ksoftirqd/x 100% (rx port)
  ksoftirqd/y 100% (tx port)
  qemu-kvm    100%
  vhost_net   100%
  ovs-vswitchd 100% (pmd thead)

Or with need_wakeup, it's lower than this number?

Thanks
William
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to