Speeding up ipq_issue_verdict (snort_inline)
Harald Welte
laforge at netfilter.org
Wed Sep 28 10:17:11 CEST 2005
On Mon, Sep 26, 2005 at 11:26:29AM -0600, Dave Remien wrote:
> Harald,
Hi Dave!
I've cc'ed netfilter-devel, to let others know about your proceedings.
> OK, I've got snort_inline plumbed up with libnfnetlink_queue and
> operational. This will allow us to run multiple copies of snort; a major
> win. The throughput (i.e., netfilter to snort and back) appears to be
> exactly the same as ip_queue, so the desire to return multiple ACCEPTS is
> still there for the longer term.
Ok, I'm quite happy to hear that even without optimizing the code (but
adding some more abstraction, like TLV encoding and more levels of API)
we didn't fuck up performance. That's good to know.
Multiple accept's should be quite feasible. Please first try to send
multiple verdict messages in one nfnetlink packet. If you have problems
implementing that, please let me know.
Only if that turns out to give little/almost no benefit, I would
implement a dedicated message type to experiment with.
> I'll try some instrumenting/profiling to
> see what the apparent bottle neck is now (the 2.6.14 kernel isn't that
> stable yet, so this might take some time). One thing:
great!
> nfa[NFQA_TIMESTAMP-1], as in
>
> if (nfa[NFQA_TIMESTAMP-1]) {
> struct nfqnl_msg_packet_timestamp *ts =
> NFA_DATA(nfa[NFQA_TIMESTAMP-1]);
>
> is never true. Apparently I'm not enough of a C programmer to know what
> I'm doing wrong.
Timestamping has to be explicitly turned on in the kernel. So if you
need an accurate receive timestamp (which adds more work to the network
RX path), you need to enable it. I don't know whether there's some
magic sysctl, but if you open a AF_PACKET socket (like starting
tcpdump), the timestamps should suddenly be there.
--
- Harald Welte <laforge at netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20050928/d4d3d592/attachment.pgp
More information about the netfilter-devel
mailing list