<div dir="ltr">ethtool -C em1 rx-usecs 1 adaptive-rx off<div>ethtool -G em1 rx 4096 tx 4096</div><div>for x in tso gro lro gso tx tx sg; do ethtool -K em1 $x off; done</div><div>ethtool -N em1 rx-flow-hash tcp4 sdfn</div><div>ethtool -N em1 rx-flow-hash udp4 sdfn</div><div><br></div><div>This is on El Repo kernel 4.12.0-1.el7.elrepo.x86_64.</div><div><br></div><div>tpacket-v3 is set to yes. (obviously mmap is true).</div><div><br></div><div>Hope this helps.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 15, 2017 at 5:31 PM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jul 14, 2017 at 3:44 PM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
> Sean, thanks for this. I think I had actually googled up your paper before.<br>
> :) This memory calculator is very nice.<br>
><br>
> I noticed that when I squashed rss queue to 1 on a 4.12 kernel, I went from<br>
> less than .05% packet loss to ~9% packet loss. Any idea why that might have<br>
<br>
</span>If the only change you did was to switch to 1 RSS then it will be<br>
interesting to understand why.<br>
But it will be good to understand your NIC settings first in terms of<br>
ring descriptor size, coalescence, what was the CPU cache misses<br>
before and after etc..<br>
<div><div class="h5"><br>
> occured? I have read some conflicting things about rss queues depending on<br>
> kernel version, namely this bit:<br>
><br>
> AF_PACKET: 1 RSS queue and stay on kernel <=4.2 or make sure you have<br>
>>=4.4.16, >=4.6.5 or >=4.7. Exception: if RSS is symmetric cluster-type<br>
> 'cluster_qm' can be used to bind Suricata to the RSS queues. Disable NIC<br>
> offloading except the rx/tx csum.<br>
><br>
> from<br>
> <a href="https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Packet_Capture" rel="noreferrer" target="_blank">https://redmine.<wbr>openinfosecfoundation.org/<wbr>projects/suricata/wiki/Packet_<wbr>Capture</a><br>
><br>
> Thank you for all the help tuning out memory issues suri. My goal is to try<br>
> and get packet loss below .01%. Heres for trying!<br>
><br>
><br>
> On Fri, Jul 14, 2017 at 9:23 AM, Cloherty, Sean E <<a href="mailto:scloherty@mitre.org">scloherty@mitre.org</a>><br>
> wrote:<br>
>><br>
>> I’ve post this earlier and hope that this can be useful.<br>
>><br>
>><br>
>><br>
>> If you are using AF-PACKET (and why wouldn't you), the attached<br>
>> spreadsheet may help.  It is derived from Peter Manev's highly detailed<br>
>> review of various configuration options and their affect on memory<br>
>> utilization.<br>
>> <a href="http://pevma.blogspot.com/2015/10/suricata-with-afpacket-memory-of-it-all.html" rel="noreferrer" target="_blank">http://pevma.blogspot.com/<wbr>2015/10/suricata-with-<wbr>afpacket-memory-of-it-all.html</a><br>
>><br>
>><br>
>><br>
>> I began creating this during a Suricata training class so I could save<br>
>> time when testing different configurations.  Peter has reviewed it for<br>
>> accuracy and correct nomenclature.  I hope that it will be of some use to<br>
>> the community.<br>
>><br>
>><br>
>><br>
>> Sean Cloherty<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> From: Oisf-users<br>
>> [mailto:<a href="mailto:oisf-users-bounces@lists.openinfosecfoundation.org">oisf-users-bounces@<wbr>lists.openinfosecfoundation.<wbr>org</a>] On Behalf Of<br>
>> erik clark<br>
>> Sent: Thursday, July 13, 2017 07:58 AM<br>
>> To: Open Information Security Foundation<br>
>> <<a href="mailto:oisf-users@lists.openinfosecfoundation.org">oisf-users@lists.<wbr>openinfosecfoundation.org</a>><br>
>> Subject: Re: [Oisf-users] SEPTun and memory usage<br>
>><br>
>><br>
>><br>
>> All, trying to find out who has worked with the SEPTun document that can<br>
>> provide some insight into how much memory they are using to sniff traffic.<br>
>><br>
>><br>
>><br>
>> We (were) using 8 threads with 200 gigs of ram on a 2.5 Gb/s link. Until<br>
>> earlier this week, our drop rate was ~2%. I just moved up to 16 threads,<br>
>> still at 200 gigs of ram, since our throughput moved up a bit to ~3.1Gb/s<br>
>> and saw a 12% drop rate.<br>
>><br>
>><br>
>><br>
>> We have 72 cores to work with, and 200 gigs of ram, and just moved to a<br>
>> 4.4 kernel from a modified 3.10 kernel. What seems reasonable on this kind<br>
>> of hardware? We are limited to an 82598 ixgbe interface with a single link.<br>
><br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@<wbr>openinfosecfoundation.org</a><br>
> Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/<wbr>support/</a><br>
> List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.<wbr>openinfosecfoundation.org/<wbr>mailman/listinfo/oisf-users</a><br>
><br>
> Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
> Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/<wbr>training/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>