<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yes, the autofp run mode is probably more in line with what you want. In that scenario it should still spawn 1 acquisition thread per stream, but the number of detect threads not be tied to it and should spawn many more threads.<div><br><div apple-content-edited="true">
<div>Matt Keeler</div><div>nPulse Technologies, Inc.<i><br></i></div><div><a href="mailto:mk@npulsetech.com">mk@npulsetech.com</a></div><div><br></div><br class="Apple-interchange-newline">
</div>
<br><div><div>On Dec 13, 2012, at 11:55 AM, Stefano Debenedetti <<a href="mailto:ste@demaledetti.net">ste@demaledetti.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello Matt,<br><br>thanks for your answer, please see inline:<br><br>Il 13/12/2012 17:36, Matthew Keeler ha scritto:<br><blockquote type="cite">With 3GD in Suricata the threading configuration is done by Suricata. It uses the builtin auto, autofp or workers run modes with workers being the most efficient in my testing.<br><br>The built in workers run mode will use one thread per stream configured using NTPL. If you want 8 threads, then you should configure 8 streams.<br></blockquote><br><br>In my understanding, in workers mode all the work on a single packet<br>(not only capture but also decoding, detection, ...) is done on a<br>single thread. If this is true then I won't achieve to split the<br>work between 8 cores for capturing and forwarding and the other 24<br>cores for doing the rest of the work (decoding, detection, ...).<br><br>On the other hand, I don't want to use more than 8 streams for<br>capturing and forwarding because in my tests it gave worse<br>performance than with 8 streams.<br><br>Therefore, I guess my only option is autofp, is this correct?<br><br>ciao<br>ste<br><br><blockquote type="cite">As for the flow pinning the Napatech card can do it or you can have<br></blockquote>it round robin packets to the individual streams. As for the flow<br>pinning in Suricata, someone else can provide a more in depth answer<br>on the subject.<br><blockquote type="cite"><br>Matt Keeler<br>nPulse Technologies, Inc.<br><a href="mailto:mk@npulsetech.com">mk@npulsetech.com</a><br><br>On Dec 13, 2012, at 11:16 AM, Stefano Debenedetti <ste@demaledetti.net> wrote:<br><br><blockquote type="cite">hello,<br><br>I'm happy to see that 3rd generation drivers support for Napatech<br>cards is going to be in 1.4.<br><br>I am testing a NT20E2 In-Line card [1] and using Napatech's example<br>packet forwarding program I found out that the best performance is<br>achieved with 8 cores (0 packet drop with full-duplex 10G link fully<br>saturated at any packet size) but I have 32 cores on my test machine<br>so I would like to use the other 24 cores for packet decoding,<br>reassembly and detection.<br><br>I find Suricata's threading configuration a bit hard to understand,<br>could anybody please point me to an example of how to do this?<br><br>Another question: the card has its own hardware-based 5-tuple<br>bi-directional flow-pinning functionality that will make packets<br>from same flow stay on the same core, in a setup like what I<br>described above there would be another layer of flow-pinning made in<br>software by Suricata, right?<br><br>Thanks ciao<br>ste<br><br>[1]<br>http://www.napatech.com/products/in-line_adapters/2x10g_pcie_nt20e2.html<br>_______________________________________________<br>Suricata IDS Users mailing list: oisf-users@openinfosecfoundation.org<br>Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/<br>List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users<br>OISF: http://www.openinfosecfoundation.org/<br></blockquote><br><br>--------------------------------------------------------------------<br>The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's organization for planning purposes only. Further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement.<br><br></blockquote>_______________________________________________<br>Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>Site: <a href="http://suricata-ids.org">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/">http://suricata-ids.org/support/</a><br>List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>OISF: <a href="http://www.openinfosecfoundation.org/">http://www.openinfosecfoundation.org/</a><br></blockquote></div><br></div></body></html>
<pre>--------------------------------------------------------------------
The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's organization for planning purposes only. Further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement.