From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] shaping incoming with ingress
Date: Thu, 31 Jul 2003 03:00:44 +0000 [thread overview]
Message-ID: <marc-lartc-105962051017303@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105960881709594@msgid-missing>
Good questions Damion,
: I've noticed as of late, everyone saying 'you can't shape incoming
: traffic' but the best solution is to use the imq device.
Well....(you'll love this) the reason everyone is saying "you can't shape
incoming traffic" is because you can't shape incoming traffic (without
IMQ).
Well, in short, what we're really saying is that you can't control what
you receive (without IMQ). As the recipient of frames/packets, you have
no control over how fast they arrive in your device's input queue.
: what happened to ingress /policer usage? is this not recommended
: anymore?
There's nothing at all wrong with using an ingress policer. I don't
believe it's possible to attach any classes to the ingress qdisc*. That
is, the ingress qdisc only exists to allow the user to police inbound
traffic.
So, using the ingress qdisc as a dummy qdisc against which to attach a
policing filter (which drops traffic over a given rate) is the only use of
the ingress qdisc.
: I know it doesn't do as efficient job as the normal egress
: methods, but is imq a lot better ?
IMQ allows the full expressiveness of the entire set of linux
traffic control tools (from egress filtering) to be applied to
- ingress traffic redirected through the IMQ device and
- traffic split across any number of interfaces regardless of
flow direction
: when does imq become necessary instead of cbq/htb and ingress?
IMQ becomes necessary when
- needing to shape or prioritize traffic on multiple interfaces as a
single unit
- desiring to shape or prioritize ingress traffic beyond policing a rate
- needing to shape or prioritize traffic regardless of flow direction
-Martin
* Maybe somebody will step in and contradict me here?
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-07-31 3:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-30 23:45 [LARTC] shaping incoming with ingress Damion de Soto
2003-07-31 3:00 ` Martin A. Brown [this message]
2003-07-31 3:55 ` Rio Martin.
2003-07-31 5:50 ` smohan
2003-07-31 9:46 ` Stef Coene
2003-07-31 9:46 ` Stef Coene
2003-07-31 9:56 ` Rio Martin.
2003-07-31 11:34 ` Stef Coene
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=marc-lartc-105962051017303@msgid-missing \
--to=mabrown-lartc@securepipe.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.