All of lore.kernel.org
 help / color / mirror / Atom feed
From: caster@postech.ac.kr
To: netfilter-devel@lists.netfilter.org
Subject: TIMEBLOCK and performance
Date: Thu, 10 Oct 2002 20:16:15 +0900	[thread overview]
Message-ID: <20021010.AAA1034248479@postech.ac.kr> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 1839 bytes --]

Thanks to reply my question.

 

Sorry to make a trivial question on the nefilter-dev board.

But, I just try to make a initiative that meets  both performance of netfilter and 

Solving problem of immidate apply of reject rule for currently using session.

 

If ACCEPT rule about Established session on the top of forward chain in iptables is not there 

, and 5 thousands of rule with timeblock is resided before ACCEPT rule about Establsihed session 

 

think. 

 

How many CPU cycle is consumed for the packet which do not match timeblock rule before Establish one?

What happens If there is 500Mbit/s flow with 64bytes in there .

 

I test netfilter firewall with gigabit NIC in my school. And I think that netfilter should be modified to support full-duplex

1 gigabit flow with 64 bytes.( I hope) 

 

My linux box is dual Xeon with 2giga ram. But it¡¯s performance in gigabit environment is not good. And

What do not happen in100M environment occurs like ULOG and LOG problem.

 

so, I want to put the Established-state accepting rule on the top of  FORWARD chain . 

 

and to solve the problem of immidate apply of reject rule for currently using session when Established-state accepting rule

is on the top of FORWARD chain , 

I try to reestimate the session in particular moment. 

 

It Reads the conntrack entry in hash and redo do_iptables() in FORWARD chain except state-matching rule.

And if existing session can¡¯t pass the chain , run their timer fuction and destroy it.

 

Do You think that it works correctly?

 

And one more Question.

I just wanna improve performance of netfilter in gigabit environment.

What do you think netfilter¡¯s bottleneck is?

And which part of kernel is modified to optimize performance?

 

wizard







[-- Attachment #1.2: Type: text/html, Size: 2312 bytes --]

             reply	other threads:[~2002-10-10 11:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-10 11:16 caster [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-10-10 11:54 TIMEBLOCK and performance caster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021010.AAA1034248479@postech.ac.kr \
    --to=caster@postech.ac.kr \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.