[Oisf-devel] innovation

[Dave Remien]

On Mon, Aug 23, 2010 at 3:52 AM, Victor Julien <victor at inliniac.net> wrote:

> m wrote:
> >> The main issue with nfqueue is performance. As discussed with Victor
> >> Julien once, it is not possible to exceed a certain number of packets
> >> per second (even if hardware is improved). This limit is quiet annoying
> >> and a better/faster queuing mechanism has to be developped to fix this
> >> issue.
> >
> > No, the main issue with nfqueue is that it is a terminating target and
> > diverts the packet to the next table, instead of going to the next rule
> > in the table.
> > The kernel can buffer packets pretty fast, that's it's specialty.
>
> Moving Suricata into the kernel seems like the wrong solution for fixing
> that issue. Writing a new and better queuing mechanism would make more
> sense.
>
> Cheers,
> Victor
>
>
Victor is 100% right. If you're using Netfilter, you could write your own
module to put packets into user space, and forward (or drop them) as needed.
Or hire Patrick McHardy to do it for you 8-).   Nfqueueing is a general
purpose mechanism to allow multiple queues of packets to user space
processes. Performance was secondary to functionality.

If you're looking for maximum throughput, it would be better to hook the
packet either at the driver or in the bridge module, and avoid Netfilter
completely, at least for IPS mode. Development makes for exciting kernel
crashing...

Running Suricata in the kernel can be done, but I doubt that it's worth the
effort.  32 bit kernels need not apply; there's not enough low mem
(typically) to run Suricata in with any kind of rule set (as I believe
Victor has already pointed out). 64 bit kernels, now, that's a different
story.

Cheers,

Dave

-- 
"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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-devel/attachments/20100823/dd5a0ad6/attachment-0002.html>