That were my results as well. It would be worthwhile to investigate how the hash is generated in the kernel. I remember, somewhere in the original patch that introduced this functionality, developers decided to let the hardware generate rxhash and pass it to user space to avoid L1 cache miss.
As we all know, 82599 hashing is no symmetric. But in my testing both a->b and b->a traffic goes correctly to the same cluster. Maybe the hardware hash is not used at all? I will dig deeper. On Thu, May 7, 2015 at 12:02 AM, Daniel Borkmann <[email protected]> wrote: > On 05/06/2015 11:52 PM, Daniel Borkmann wrote: >> >> Sorry for the late answer. >> >> On 05/01/2015 02:53 PM, [email protected] wrote: >> ... >>>> >>>> Interesting, lets say if you use --fanout-type lb, would that make a >>>> difference? >>>> >>>> This should round robin each packet between these 3 processes, so you >>>> should >>>> definitely see something unless we have a bug. ;) Let me know, so we can >>>> look >>>> further ... >>> >>> >>> no change if using --fanout-type lb. I see all 3 instances run and show >>> similar CPU % in top, but only last file seems to be on my SSD. >>> BTW, --fanout-type qm returns "$ Cannot set fanout ring mode!", that's >>> why I switched to type cpu. ( considering I use irq affinity script to lock >>> Rx queues to certain CPUs and also I lock netsniff-ng, I guess it doesn't >>> matter which one I use cpu or qm ) >> >> >> The qm won't work in your case since your kernel is too old. >> >> So I was just using the following: >> >> netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag >> --ring-size 128MiB --bind-cpu 0 --notouch-irq --silent \ >> --in lo --out /tmp/netcapture/ --prefix "a." --interval 60sec >> & >> >> netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag >> --ring-size 128MiB --bind-cpu 1 --notouch-irq --silent \ >> --in lo --out /tmp/netcapture/ --prefix "b." --interval 60sec >> & >> >> netsniff-ng --fanout-group 1 --fanout-type rnd --fanout-opts defrag >> --ring-size 128MiB --bind-cpu 2 --notouch-irq --silent \ >> --in lo --out /tmp/netcapture/ --prefix "c." --interval 60sec >> & >> >> And doing a ping 127.0.0.1, gives me pcap files in /tmp/netcapture/ with >> all three {a,b,c}. >> prefixes; plus after 60sec they start a new one. >> >> I've also tried two instances dumping to two different files with various >> fanout-types, >> they seem to work as expected. That means that fanout in general seems to >> function. >> >> The only issue (as I don't know what traffic you're seeing) could be that >> your rxhash >> always falls into fanout member with that prefix, strange. >> >> Does the above example work for you on loopback? If you have two instances >> in the same >> group outputting to a normal pcap file with rnd, do you both files get >> written? > > > Also fanout-type by hash on physical interface looks correct in my case, > f.e.: > > netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag > --ring-size 128MiB --bind-cpu 0 --notouch-irq --silent \ > --in wlp2s0b1 --out /tmp/netcapture/ --prefix "a." --interval > 60sec & > > netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag > --ring-size 128MiB --bind-cpu 1 --notouch-irq --silent \ > --in wlp2s0b1 --out /tmp/netcapture/ --prefix "b." --interval > 60sec & > > netsniff-ng --fanout-group 2 --fanout-type hash --fanout-opts defrag > --ring-size 128MiB --bind-cpu 2 --notouch-irq --silent \ > --in wlp2s0b1 --out /tmp/netcapture/ --prefix "c." --interval > 60sec & > > E.g. if I'm running ping 8.8.8.8, then that /only/ lands with some other > stuff in c's pcap, > which is as expected. > > Cheers, > Daniel > > > -- > You received this message because you are subscribed to the Google Groups > "netsniff-ng" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "netsniff-ng" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
