[Oisf-devel] Cannot saturate bandwidth even with zero rules

[Victor Julien]

Can you try the attached patch? It simplifies the runmode and reduces
the number of threads a packet has to travel through.

Cheers,
Victor

Jen-Cheng(Tommy) Huang wrote:
> Hi Dave,
> 
> Thanks for your response.
> I was using snort 2.8 which did not use DAQ and I compiled it with
> --enable-inline.
> And the inline mode is using libipq.
> I rerun the test yesterday and I found that preprocessors in snort could
> affect the throughput.
> In normal snort inspection procedure, it has decode -> preprocess ->
> inspect phases.
> When I used packet logging mode in snort where no preprocessors is used
> and packet were only decoded, snort was able to run up to line speed
> (941 Mbps).
> The second case is that when I used IPS mode without any rules loaded,
> the default preprocessors, such as stream5, frag3, http those were still
> working and that made the throughput dropped down to 7xx Mbps.
> Does it make sense?
> 
> Thanks,
> Tommy
> 
> On Tue, Nov 9, 2010 at 8:08 PM, Dave Remien <dave.remien at gmail.com
> <mailto:dave.remien at gmail.com>> wrote:
> 
>     Tommy,
> 
>     Could you describe the snort configuration you used a little more?
>     Snort compiled with --enable-inline-init-failopen and the DAQ stuff?
>     Or some other method? If using nfq/ipq, what's your iptables config?
>     Are you perchance using jumbo packets to test with?
> 
>     I ask because I've never seen a single nfqueue instance (or ipqueue,
>     but that's really a wrapper around nfqueue) be able to forward
>     packets at that rate on any x86* platform. Well, so far.
> 
>     Cheers,
> 
>     Dave
> 
> 
>     On Tue, Nov 9, 2010 at 11:42 AM, Jen-Cheng(Tommy) Huang
>     <thnbp24 at gmail.com <mailto:thnbp24 at gmail.com>> wrote:
> 
>         Hi Victor,
>         Thanks for your suggestion.
>         I have tried a couple values of max-pending-packets, but the
>         throughput was at most 7xx Mbps.I've tried very large values,
>         such as 2000, 4000, or 10000, but the throughput did not make
>         much difference. It was all around 7xx Mbps. I am sure that I
>         used the right config. When I changed the value to 1, the
>         throughput dropped down to 1xx Mbps. Any other setting I should
>         change? BTW, the command that I used was "suricata -c
>         /etc/suricata/suricata.yaml -q 0". And I did not use dropping
>         privilege package since I ran it as root. All rules were not loaded.
>         Thanks.
> 
>         Tommy
> 
> 
> 
>         On Tue, Nov 9, 2010 at 4:21 AM, Victor Julien
>         <victor at inliniac.net <mailto:victor at inliniac.net>> wrote:
> 
>             Jen-Cheng(Tommy) Huang wrote:
>             > Hi,
>             >
>             > I just tested suricata inline mode without pf_ring feature.
>             > My NIC is intel 1Gbps NIC.
>             > I used netperf TCP_MAERTS as my benchmark.
>             > When I removed all rules, I supposed suricata should run
>             up to 941 Mbps
>             > which was what I observed in snort.
>             > However, I could only see around 700 Mbps. And with the
>             default rule set
>             > which I downloaded from emergingthreats.net
>             <http://emergingthreats.net>
>             > <http://emergingthreats.net/>, the throughput became 4xx
>             Mbps. The
>             > strange thing was all CPUs were not saturated. (intel core
>             i7).Thus, I
>             > supposed the cpus were not the bottleneck. But why it
>             couldn't saturate
>             > the bandwidth?
>             > Any idea?
> 
>             Tommy, you could try to increase the max-pending-packets
>             setting in
>             suricata.yaml. It defaults to 50. The really high speed
>             setups I've seen
>             usually require a setting more in the range of 2000 to 4000.
>             It will
>             cost quite a bit of extra memory though.
> 
>             Let me know if that changes anything.
> 
>             Cheers,
>             Victor
> 
>             --
>             ---------------------------------------------
>             Victor Julien
>             http://www.inliniac.net/
>             PGP: http://www.inliniac.net/victorjulien.asc
>             ---------------------------------------------
> 
> 
> 
>         _______________________________________________
>         Oisf-devel mailing list
>         Oisf-devel at openinfosecfoundation.org
>         <mailto:Oisf-devel at openinfosecfoundation.org>
>         http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> 
> 
> 
> 
>     -- 
>     "Of course, someone who knows more about this will correct me if I'm
>     wrong, and someone who knows less will correct me if I'm right."
>     David Palmer (palmer at tybalt.caltech.edu
>     <mailto:palmer at tybalt.caltech.edu>)
> 
> 


-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Simplify-NFQ-runmode-reducing-the-number-of-threads-.patch
Type: application/mbox
Size: 6173 bytes
Desc: not available
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20101111/f3365798/attachment.mbox>