On Thursday, May 7, 2015 at 11:40:02 AM UTC-5, Daniel Borkmann wrote: > On 05/07/2015 06:22 PM, [email protected] wrote: > ... > > I didn't see much difference in lb vs hash mode when it comes to output > > file sizes and CPU utilization, > > but let me know if one has advantage over the other in some form or fashion. > > It probably depends on what you want. ;) So from the fanout demuxing > disciplines (lb vs hash vs cpu) themselves, cpu seems to be the most > lightweight (haven't measured them yet), i.e. it's just a cpu % > fanout-group-size. > With lb, you obviously need synchronization with regards to demuxing > to a group member (that is, 2 atomic reads, 1 atomic cmpxchg) and > with fanout hash, worst case you have to go into the kernel flow dissector > to pick up flow keys to generate a l4 hash to demux over. If you can > distribute the load via RSS and the use cpu, or on newer kernels, qm, > then that's probably most lightweight. hash or a combination with RSS > and cpu/qm, I find useful since it allows flows to stay pcap-local > unlike lb. > > Cheers, > Daniel
Hi Daniel, sounds good. I will try distributed load via RSS and fanout cpu, and on some machines which for some reason keep hitting just one IRQ ( I have myricom 10G card configured with myri10ge_max_slices=8 but Rx keeps hitting just one IRQ all the time), will try to go for hash rather than lb. Regards Ivan -- 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.
