On 04/11/2015 06:59 PM, Michał Purzyński wrote:
OK, try one. I'm ready to accept heavy artillery fire ;-) Man, it
takes a while to find a free letter for getopt.
Two new parameters were added:
-C <cluster id> with integer that represents the socket fanout group
identifier and must be shared between all processes in the group
-K hash/lb/cpu/rnd - the type of fanout. The only really useful here
is "hash" because it preserves flows. If it is choosen, kernel side
defragmentation is enabled as well (fragments would have different
hash).
I'd prefer if we name it "fanout-type" and "fanout-group" perhaps,
that way it's clear that we mean the packet-sockets fanout mechanism.
What do you think?
Other than that, there's a couple of more fanout disciplines:
http://lingrok.org/xref/linux-net-next/net/packet/af_packet.c#1371
So it would be: hash/lb/cpu/rnd/qm/roll
I think we might need to describe the exact meaning of that in the
--help option. But I'm totally fine if we do that as follow-up.
Now, kernel does not allow to choose what we are hashing on, and it
seems to be 4-tuple.
With QM (queue-mapping), you can just use the NICs HW queue flow
steering for the fanout group distribution.
I tested it with lb and hash cluster types and everything worked. The
That's great.
lb cluster type is useless (as is anything that is not "hash" but
given how advanced the nesniff-ng software is, someone might find it
useful and it's just a few lines more.
Sure, if we add it, we might also want to give the user a choice. I
think that hash/cpu/qm and roll (== moves to the next fanout socket
after the first's queue is full) might be useful.
--
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.
