[Oisf-users] Packet drops on core 0 when file extraction is enabled?

Cooper F. Nelson cnelson at ucsd.edu
Fri Jan 31 15:37:10 UTC 2014

Hash: SHA1

On 1/31/2014 1:08 AM, Eric Leblond wrote:

> It could be interesting to compare the work done on CPU 0 and on the
> other CPUs. You can use linux-tool for that by running perf top. To get
> info on core 0:
> 	perf top -C 0
> Then compare with another CPU:
> 	perf top -C 1
> Regarding your point about file tracking. Are you doing file
> extraction ? If that's the case maybe there is interference with output
> device (maybe check interrupts to see if CPU 0 is handling the block
> device).
> BR,

Ok, my mind == blown at the moment.  Have not used that tool before.

Indeed, the function 'sk_run_filter' periodically rises to ~30% on core
0 while it remains at ~8% on core 1.  I suspect this is due to bursts of
'crap' packets on our network telescope.

So, I guess my question now is, what happens to 'good' packets that are
steered to core 0?  I'm not running a worker thread on that core, so I'm
hoping they get steered elsewhere?

I think my issue is that I don't get how the 'auto flow-pinning' really
works at a low-level.  I'm thinking now that packets are "steered" by
the main suri process to whatever core has the least packets/flows, so
while a flow may be directed to queue 0 by the nic/driver/kernel, the
packets will ultimately be copied to a different core?

Basically, I want to make sure I'm not dropping the 'good' packets that
are being processed by core 0.

- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Oisf-users mailing list