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.
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.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
