On Wed, Aug 30, 2023 at 6:17 PM David Marchand <david.march...@redhat.com> wrote: > > On Wed, Aug 30, 2023 at 6:09 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > > > > On 8/30/23 18:02, David Marchand wrote: > > > On Wed, Aug 30, 2023 at 1:45 PM Ilya Maximets <i.maxim...@ovn.org> wrote: > > >>> +# Fake a veth by creating a tap on kernel side and plug it in OVS > > >>> using the > > >>> +# net/tap DPDK driver. > > >> > > >> Why do we need to fake a veth? It looks strange to me and also error > > >> prone > > >> as taps do not behave like veths in some cases. Can we just have a veth > > >> and > > >> open it with af_packet ports like all other testsuites do? > > > > > > When you suggest af_packet port, I suppose you mean netdev-afxdp ports. > > > > No, I meant DPDK's drivers/net/af_packet/rte_eth_af_packet.c. > > That's something I can investigate, though it's been a long time (in a > previous life) since I played with it. > In comparison net/tap seems widely used to me. > > /me opens https://bugs.dpdk.org/enter_bug.cgi in preparation
- As for net/af_packet, it uses PACKET_FANOUT_FLAG_DEFRAG (with no way to disable this feature). https://git.dpdk.org/dpdk-stable/tree/drivers/net/af_packet/rte_eth_af_packet.c?h=22.11#n763 https://git.dpdk.org/dpdk-stable/tree/drivers/net/af_packet/rte_eth_af_packet.c?h=22.11#n879 This does not play well with OVS tests like when pinging with oversized packets. The reassembled packets are received on the DPDK port and then get dropped when trying to send them because the packets exceed the port mtu. I don't think this is something we can live with. - About net/af_xdp, after some ethtool tweaking on the "kernel-facing" netdev (same as system-afxdp tests) to disable tx offloads, the tests pass on my fedora37 except some random failure on "conntrack - ICMP related" tests with following logs: +2023-08-30T19:41:54.364Z|00001|dpif(revalidator17)|WARN|netdev@ovs-netdev: failed to flow_get (No such file or directory) ufid:3e239a2e-e9ff-42e9-a6b1-bfeeb0b511a9 <empty>, packets:0, bytes:0, used:never +2023-08-30T19:41:54.364Z|00002|ofproto_dpif_upcall(revalidator17)|WARN|Failed to acquire udpif_key corresponding to unexpected flow (No such file or directory): ufid:3e239a2e-e9ff-42e9-a6b1-bfeeb0b511a9 This does not seem related as it goes away on a retest, but I hit it in two different runs, is this something known? As a note, there is no issue with tx checksum offloading: there is no support at all in the pmd itself. -- David Marchand _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
