On 19.11.2019 21:09, William Tu wrote: > 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?
Disable Tx offloading on both p0 and br0 and it will work. > > --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> >>> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
