I tried setting the MAC addresses. In my local test, the problem disappeared, but I doubt that it's been fixed.
On our larger testbed, with OpenVPN tunnels, the bug persists event with the MAC addresses. But our setup may be problematic, for instance in this interface chain: veth0 -|- veth1 <---> l2fwd <---> veth2 -|- veth3 we set the addresses from the endpoints (veth0, veth3), while l2fwd is attached to middle interfaces (veth1, veth2). Do you think this is interfering with the network stack? It looks like a serious bug in the kernel, then... It seems that we'll have to try netmap. -- Oriol Arcas Software Engineer Starflow Networks On Fri, Feb 17, 2017 at 1:23 PM, Elo, Matias (Nokia - FI/Espoo) < matias....@nokia-bell-labs.com> wrote: > > > On 17 Feb 2017, at 14:03, Oriol Arcas <or...@starflownetworks.com> > wrote: > > > > Hi, > > > > Thanks for your reply Marias. > > > > I tried a simpler setup and the bug persists. With a linux bridge it > works fine. > > > > My setup is the following: > > > > | nginx <---> veth0 -|- veth1 <---> l2fwd <---> veth2 -|- veth3 <---> > wget | > > > > where the | delimiters mean a network namespace. > > > > I have tried it with ODP_PKTIO_DISABLE_SOCKET_MMAP, all the different > scheduling modes and -c 1. > > > > Our next test would be using DPDK or netmap, if they can be used with > veth interfaces. > > At least netmap should work with virtual interfaces. > > More things to try with odp_l2fwd arguments: > > Set the MAC addresses correctly. Using the same MAC from multiple > interfaces > could potentially cause some issues with the host network stack. > For example: odp_l2fwd -i if1,if2 -d 1 -s 1 -r <if1_mac,if2_mac2> > > Use direct pktio mode: -m 0 > > > -Matias
