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

[Ilya Maximets]

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.

> 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>
>