From: Dzianis Kahanovich <mahatma@bspu.unibel.by>
To: netfilter@vger.kernel.org
Cc: casper@meteor.dp.ua
Subject: Re: Per IP maximal speed limit inside HTB class
Date: Wed, 16 Jan 2008 14:04:27 -0200 [thread overview]
Message-ID: <478E2B0B.4070600@bspu.unibel.by> (raw)
In-Reply-To: <1200483046.5107.17.camel@casper2.meteor.dp.ua>
Покотиленко Костик wrote:
> I already have HTB class tree which makes channel division between
> client groups.
> One of those groups now has to have clients with limited maximal speed
> to implement "unlimited" traffic billing.
>
> So the question is: is there any queueing discipline which can limit
> maximal speed for any source/destination IP with one rule so that I
> would not have to insert clases for each new IP?
There are not too nefilter questions, but while I experiment with
unconditional class 3 of PSPacer 2.1[.1]
(http://www.gridmpi.org/pspacer-2.1/index.en.jsp), I remember there are IMHO
may (with additional programming) do it. Mode 3 still not complete and fall
kernel, but I comment out estimate_target_rate() code up to "cl->rate =
cp->rate;" line and do "cl->rate = <rate>;" and IMHO rate was reached. But I
not sure about there are warrantied rate. You may try to remove "tcp" code
from PSPacer and make some kind of hash, based on source and|or destination
IP. I just not found way to use it - I prefer to bound rate for my network to
common channel and use it in concurrent way to fill channel. And not sure to
commercial-quality of rate (there are high-quality lostless scheduler, but
"warrantied" rate are not high-quality in this sense, only limited).
Else you must use not QoS (like HTB) anymore, just drop packets up the limit
with "tc filter ... policy ..." commands. There are not netfilter too.
>
> For example it would be perfect if I could make something like this:
>
> + HTB class with from 5 Mbit/s to 5 Mbit/s
> | HTB class with from 1 Mbit/s to 5 Mbit/s prio 2 (for clients without
> unlimited traffic)
> | HTB class with from 4 Mbit/s to 5 Mbit/s prio 1 (for clients with
> unlimited traffic)
> + {some limit qdisc}
> | max speed limit 128 KBit/s (for 128K unlimited traffic) prio 1
> | max speed limit 256 KBit/s (for 128K unlimited traffic) prio 2
> | max speed limit 512 KBit/s (for 128K unlimited traffic) prio 3
>
> Any hints?
>
--
WBR,
Denis Kaganovich, mahatma@eu.by http://mahatma.bspu.unibel.by
prev parent reply other threads:[~2008-01-16 16:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-16 11:30 Per IP maximal speed limit inside HTB class Покотиленко Костик
2008-01-16 16:04 ` Dzianis Kahanovich [this message]
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=478E2B0B.4070600@bspu.unibel.by \
--to=mahatma@bspu.unibel.by \
--cc=casper@meteor.dp.ua \
--cc=mahatma@eu.by \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox