From: George Alexandru Dragoi <waruiinu@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Scalability
Date: Thu, 30 Sep 2004 12:42:10 +0000 [thread overview]
Message-ID: <3063e50409300542cfe85fa@mail.gmail.com> (raw)
In-Reply-To: <3063e50409290313b61b303@mail.gmail.com>
I meant i want to block most of p2p, and allow only few of them and
shape them. So i will use connmark only for dc++ and edonkey. I want
that the bulk non p2p traffic, which is not really few, wont get
parsed by the p2p matches. Such traffic will be matched agains src ip
or dest ip, or port number (I even may may use IPMARK) which is not
CPU destroyer and wont generate bad latency. I know i should post that
to netfilter mailing list, I am still waiting for opinions.
On Wed, 29 Sep 2004 16:42:06 +0200, Andreas Klauer
<andreas.klauer@metamorpher.de> wrote:
> George Alexandru Dragoi wrote:
> > Perhaps a tweak would be to send 0x0 marked traffic to a chain and
> > apply such matches there, so really few traffic will go to p2p
> > matching.
>
> That's the way I'm doing it. But it's useful only if you're not blocking
> the p2p traffic. If you're blocking it, the connection should be closed
> anyway, so there's no need to check wether a connection was already
> marked or not. At least, ipp2p proposes it this way... you don't need
> connmark at all if you're just blocking all p2p traffic.
>
> However, the result won't be that "really few traffic" will go to p2p
> matching... it's just that the already identified p2p connections won't
> go to p2p matching again.
>
> All other traffic will still go to this chain. ipp2p has no "this is
> definitely NOT p2p" return value which would allow for further
> optimizations. You could try your luck with some other conditions, like
> if a connection was checked 10 times, don't check it again or something
> like that.
>
> HTH
> Andreas
>
>
--
Bla bla
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2004-09-30 12:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-29 10:13 [LARTC] Scalability George Alexandru Dragoi
2004-09-29 14:42 ` Andreas Klauer
2004-09-30 12:42 ` George Alexandru Dragoi [this message]
2004-09-30 13:00 ` Andreas Klauer
2004-09-30 14:11 ` George Alexandru Dragoi
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=3063e50409300542cfe85fa@mail.gmail.com \
--to=waruiinu@gmail.com \
--cc=lartc@vger.kernel.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.