[Oisf-devel] CPU affinity in PF_RING
Martin Holste
mcholste at gmail.com
Fri Jan 13 15:28:25 UTC 2012
I've been pondering this for awhile, and isn't it just inherent in the
cluster_flow hashing idea that one thread is always at risk of getting
overloaded because it's a mathematical decision which does not regard
current load per-thread? The thread which gets Akamai, Microsoft, or
Google, etc. has a high risk of getting overloaded, and it's a static
calculation that assigns that, right?
Follow-up: is autofp improving the situation by taking into account
the current load? My system with autofp seems to have high and low
threads, so I think it is suffering from the same static assignment
problem.
On Fri, Jan 13, 2012 at 9:13 AM, Chris Wakelin
<c.d.wakelin at reading.ac.uk> wrote:
> Hi,
>
> I've been using the "workers" runmode in PF_RING (with cluster_flow) for
> weeks and have just noticed it doesn't seem to pay attention to the
> set_cpu_affinity setting. Is there a good reason for this? I quite like
> the idea of tying a single receive-detect-log path to a particular CPU,
> which is one of the reasons I liked Will Metcalf's "single" runmode.
>
> The reason I'm asking is my Suricata (1.2rc1 equivalent) is getting
> "busy" at times where one thread is consuming 100% of its CPU core and
> then dropping packets. Restarting Suricata fixes it for a while. It
> doesn't appear to be load-related (well, not number of packets or bytes,
> anyway) but might be getting triggered by particular network events.
> Having CPU affinity set might help keep track of one particular thread.
>
> Best Wishes,
> Chris
>
> --
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin, c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading, Tel: +44 (0)118 378 2908
> Whiteknights, Reading, RG6 6AF, UK Fax: +44 (0)118 975 3094
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
More information about the Oisf-devel
mailing list