[Oisf-users] Napatech support in Suricata: thread configuration and flow pinning

[Stefano Debenedetti]

> On 12/13/2012 06:06 PM, Stefano Debenedetti wrote:
>> Hi Victor,
>>
>> Il 13/12/2012 17:46, oisf-users-request at openinfosecfoundation.org ha
>> scritto:
>>> Message: 4
>>> Date: Thu, 13 Dec 2012 17:38:30 +0100
>>> From: Victor Julien <lists at inliniac.net>
>>> To: oisf-users at openinfosecfoundation.org
>>> Subject: Re: [Oisf-users] Napatech support in Suricata: thread
>>> 	configuration and flow pinning
>>> Message-ID: <50CA0486.2080902 at inliniac.net>
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On 12/13/2012 05:36 PM, Matthew Keeler wrote:
>>>>> 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.
>>>>>
>>>>> 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.
>>>>> As for the flow pinning the Napatech card can do it or you can have it
>>>>> round robin packets to the individual streams. As for the flow pinning
>>>>> in Suricata, someone else can provide a more in depth answer on the subject.
>>> Is it possible to have more streams? Say 16 or 32?
>>>
>>> Cheers,
>>> Victor
>>
>>
>> Yes, it's possible to have up to 16 streams but in my testing with
>> Napatech's packet forwarding example program it gave worse
>> performance than with 8 streams, this is why I would like to split
>> the work between:
> 
> When testing with 8 streams, did you also test with rules and such?
> Performance characteristics can be quite different when rules are added
> to the mix.


I ran the test using Napatech's example program for forwarding
packets, no decoding, no detection, no rules, no Suricata.

I did it so for the purpose of finding out what is the performance
of the card and I was quite surprised to find that with 16
streams/cores there was packet loss and with 8 streams/cores there
was none.


>> * 8 cores only doing capturing and forwarding
>> * all other cores for doing decoding, detection, etc.
> 
> You could try autofp for this indeed. Possibly it would be beneficial to
> have a special mode that has one capture thread per stream, then 3 or 4
> detect/etc threads dedicated to it.


What would the benefit be on top of autofp?


> Runmodes are defined it code, but abstracted quite far already, so
> trying new modes shouldn't be very hard.


Before diving into the code I should probably give autofp a try, do
you have an example configuration for achieving the scenario I
described?


thanks ciao
ste