[Oisf-users] af-packet and Linux Kernel version

[Michał Purzyński]

We will publish every single detail in a few days. I just got back home!

Unfortunate your CPU is kind of old :( We really need those features of at least Sandy Bridge, yours is an early Nehalem version. 

I'll send a detailed troubleshooting guide in a few days. Step by step like :)

> On 15 Nov 2016, at 21:23, Cooper F. Nelson <cnelson at ucsd.edu> wrote:
> 
> Hi Michal (and great presentation!),
> 
> Turned off and verified:
> 
>> receive-hashing: off
> 
> I tried running with a single RSS queue pinned to core 0 and suricata
> running worker threads on cores 1-15, however core 0 is still at 100%
> utilization and there was massive packet loss on the NIC/bus (this will
> not show in stats.log, btw).
> 
> I tried again using cores 0-1 and suri on 2-14.  This working better and
> we are seeing lots of alerts, so maybe this is the best we can do on
> current hardware.  We will still have packet re-ordering due to timing
> issues and associated missed events, but it will be less than the other
> modes I think.
> 
> If anyone has any tips on how to max out single-core RSS performance,
> please let me know.  We are seeing 800k packets/sec peak, which is well
> under what Michal and Peters were seeing in their experiments, so I'm
> not sure what the issue is.  It's an older system, but still fairly beefy:
> 
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 6
>> model           : 26
>> model name      : Intel(R) Xeon(R) CPU           X5560  @ 2.80GHz
>> stepping        : 5
>> microcode       : 0x11
>> cpu MHz         : 2792.918
>> cache size      : 8192 KB
>> bogomips        : 5585.83
> 
> -Coop
> 
>> On 11/15/2016 11:01 AM, Michał Purzyński wrote:
>> The new afpacket from 4.4 will use card hash if rxhash variable is enabled.
>> 
>> Disable it with ethtool and verify with ethtool -k 
> 
> 
> -- 
> Cooper Nelson
> Network Security Analyst
> UCSD ITS Security Team
> cnelson at ucsd.edu x41042
>