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

[William Tu]

On Wed, Nov 20, 2019 at 05:43:48PM +0100, Ilya Maximets wrote:
> On 20.11.2019 8:35, Eelco Chaudron wrote:
> > 
> > 
> > On 19 Nov 2019, at 17:52, Ilya Maximets wrote:
> > 
> >> On 19.11.2019 17:16, 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.
> >>> Patch in general looks good, two small comments inline.
> >>
> >> Thanks for review.
> >>
> >>>
> >>> The only thing that bothers me is the worse performance of the TAP interface with the new default config. Can we somehow keep the old behavior for TAP interfaces?
> >>
> >> Could you check if TCP works over tap interfaces in generic mode?
> >> For me the point is that correctness is better than performance.
> >> I also hope that native implementation for tap will be improved
> >> over time.
> > 
> > So if I understood your email chain with William correctly TCP is not working, so I affray correctness is better than performance.
> 
> Not exactly. William didn't test the actual TAP interfaces.
> 
> I tested today with kernel vhost backed virtio-user port and it seems to pass
> TCP frames in generic mode.
> 
> The setup is following:
> 
> tap1 <-- ovs-vswitchd --> tap0 <-- testpmd --> tap2
> 
> tap1 -- tap port created by OVS (type=tap)
> tap0 -- tap port, virtio-user, created by testpmd, opened by OVS with type=afxdp
> tap2 -- tap port created by testpmd (net_tap)
> 
> tap1 and tap2 are in their own network namespaces and iperf works on them.

Hi Ilya,

This is an interesting setup.
Can you share roughly your commands to do this test?

btw, add Yiyang in the loop as he is going to try
this setup on openstack environment.

William

> 
> TCP works in this scenario regardless of xdp-mode on tap0 interface.
> 
> However, let's look at the difference before-after this patch:
> 
>                         PHY NIC              TAP              VETH
> before (skb default)  slow by default   fast by default       broken TCP
> after  (best-effort)  fast by default   slower by default     works
> 
> For the best speed before you had to configure xdp-mode for physical NICs,
> after you need to configure xdp-mode for TAPs.  No much difference from the
> configuration side, but with patch applied veths are working.
> 
> So, I think this change makes sense anyway.  We can think about workaround
> for TAP devices, but we still need to check more cases.
> 
> For now, I updated the 'Limitations' section with information that generic
> mode works for TAP devices and might be even faster in some cases.
> 
> I also reformatted the code for 'unspecified' and 'best-effort' modes as
> you asked and applied to master. 
> 
> Best regards, Ilya Maximets.