On Fri, Apr 24, 2015 at 1:15 PM, Dan Williams <d...@redhat.com> wrote: > On Thu, 2015-04-23 at 14:29 -0700, Mahesh Bandewar wrote: >> Processing multicast / broadcast in fast path is performance draining >> and having more links means more clonning and bringing performance >> down further. >> >> Broadcast; in particular, need to be given to all the virtual links. >> Earlier tricks of enabling broadcast bit for IPv4 only interfaces are not >> really working since it fails autoconf. Which means enabling braodcast >> for all the links if protocol specific hacks do not have to be added into >> the driver. >> >> This patch defers all (incoming as well as outgoing) multicast traffic to >> a work-queue leaving only the unicast traffic in the fast-path. Now if we >> need to apply any additional tricks to further reduce the impact of this >> (multicast / broadcast) type of traffic, it can be implemented while >> processing this work without affecting the fast-path. > > These patches appear to work for me for the L2 + DHCP use-case, however > I experienced some quite odd behavior when pinging the ipvlan interface > from another machine. I did this: > > ip link add link eno1 type ipvlan mode l2 > ip netns add ipv > ip link set dev ipvlan0 netns ipv > ip netns exec ipv /sbin/dhclient -B -4 -1 -v > -pf /run/dhclient-ipvlan0.pid -C adafdasdfasf ipvlan0 > ip netns exec ping 4.2.2.1 <success> > > However, when pinging from another machine, I got very inconsistent ping > replies: > > 64 bytes from 192.168.1.38: icmp_seq=1 ttl=64 time=11.4 ms > 64 bytes from 192.168.1.38: icmp_seq=16 ttl=64 time=64.9 ms > 64 bytes from 192.168.1.38: icmp_seq=25 ttl=64 time=87.9 ms > 64 bytes from 192.168.1.38: icmp_seq=30 ttl=64 time=242 ms > 64 bytes from 192.168.1.38: icmp_seq=35 ttl=64 time=40.1 ms > 64 bytes from 192.168.1.38: icmp_seq=36 ttl=64 time=60.9 ms > We know that there is that PAUSE frame leak but that should not cause this behavior if those are present in your network. The sched_work() which is wrong (as pointed by Eric) especially when the machine is busy and that might trigger something like this. Almost every 10th - 15th ping packet seems to be processed correctly.
I did get consistent results as opposed what you have shown here, but will dig some more to see if something obviously wrong here. > But I cannot reproduce that in a second run (though I haven't rebooted > to test cleanly again). > > And oddly, the dhclient process takes a consistent 5% CPU and wireshark > running on eno1 (not even the ipvlan interface) jumps to 100% CPU along > with the dumpcap process taking another 25%, none of which are normal. > This is a 4-core i4790 box, so something is wrong here; is something > holding onto a spinlock for way too long? > > But at least it handles the packets ok, so I say progress! Happy to > help track down the CPU usage issue if you want to give me patches to > test. > Which patch(es) you are referring to? > Dan > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
