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