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

[William Tu]

On Tue, Nov 19, 2019 at 08:51:19PM +0100, Ilya Maximets wrote:
> On 19.11.2019 20:45, William Tu wrote:
> > On Tue, Nov 19, 2019 at 05:52:22PM +0100, 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.
> >>
> > 
> > I agree that we should first make sure correctness.
> > I created a simple TCP test using br0, since br0 is a tap device.
> > Unfortunately it does not work...
> > 
> > ---
> > ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev
> > 
> > ip netns add at_ns0
> > ip link add p0 type veth peer name afxdp-p0
> > ip link set p0 netns at_ns0
> > ip link set dev afxdp-p0 up
> > 
> > ovs-vsctl add-port br0 afxdp-p0
> > ovs-vsctl -- set interface afxdp-p0 options:n_rxq=1 type="afxdp" options:xdp-mode=native
> > 
> > ip netns exec at_ns0 sh << NS_EXEC_HEREDOC
> > ip addr add "10.1.1.1/24" dev p0
> > ip link set dev p0 up
> > NS_EXEC_HEREDOC
> > 
> > ovs-vsctl -- set interface br0 options:n_rxq=1 type="afxdp" options:xdp-mode=native
> 
> I'm not sure if this is a valid thing to do.
> After changing the netdev type this device is no linger TAP device.
> Now it's a permanent tap device that detached from any application
> and opened by af_xdp from the other side.
> 
> BTW, changing the type of "internal" port doesn't sound safe.

I see, thanks.

Then if we don't change br0 to afxdp type, the TCP test
below still fails, which I think should pass because
we are using native mode for veth now.

I think even native mode doesn't work for TCP?

--William
> 
> > ip addr add "10.1.1.2/24" dev br0
> > ip link set dev br0 up
> > 
> > # UDP works ok
> > ip netns exec at_ns0 nc -u -l 1234
> > nc -u 10.1.1.1 1234
> > <works ok>
> > 
> > # TCP still fails
> > ip netns exec at_ns0 nc -l 1234
> > nc 10.1.1.1 1234
> > <no reponse>
> >