For police, implement overhead parameter parsing.
The change is ABI (Application Binary Interface) backward compatible
with older kernels, but will first have effect from kernel 2.6.24.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
For CBQ, implement overhead parameter parsing.
The change is ABI (Application Binary Interface) backward compatible
with older kernels, but will first have effect from kernel 2.6.24.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
Change CBQ to use matches() function instead of strcmp().
This resembels the usage in other parse functions, and allows
partial command parameter matching.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
For TBF, implement overhead parameter parsing.
The change is ABI (Application Binary Interface) backward compatible
with older kernels, but will first have effect from kernel 2.6.24.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
update: Fix the spelling of "hexidecimal"
This updates the help output to specify that CLASSID should be hexidecimal.
This makes sure that a user entering "flowid 1:10" gets his flow put into
band 15 (0x10) and knows why.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
commit 94e9cba778cb97d77d9146dc3bd38ff195bc2c8a
Author: Patrick McHardy <kaber@trash.net>
Date: Sat Feb 2 18:22:16 2008 +0100
[IPROUTE]: cls_flow: add vlan-tag support
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
[IPROUTE]: Add flow classifier support
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
[...]
> Commands like "tc filter add dev ppp0 parent ffff: protocol ip prio 50
> u32 match ip src 0.0.0.0/0 police rate 4mbit burst 10k drop flowid :1"
> apparently no longer works. The flowid is not accepted anymore.
> Reverting commit 720a2e8d99... which you authored seems to "fix" this.
[...]
After further investigation it seems clear to me that reverting the
commit 720a2e8d990707749b2... is the correct thing to do, since the real
fix for the problem this commit was supposed to fix was instead fixed in
commit c29391c7c68f031e246c...
Whatever you specify after a u32 police you will now get a syntax error,
and according to "tc filter add u32 help" there are several things that
you are supposed to be able to specify after a police.
This reverts commit 720a2e8d99.
New iptables 1.4.0 has some library names changed from libipt to libxt.
It is prefferable also to open libxt_ first, as newer "style".
Signed-off-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
Patrick McHardy, Cite: 'its better to overestimate than underestimate
to stay in control of the queue'.
Illustrating the rate table array:
Legend description
rtab[x] : Array index x of rtab[x]
xmit_sz : Transmit size contained in rtab[x] (normally transmit time)
maps[a-b] : Packet sizes from a to b, will map into rtab[x]
Current/old rate table mapping (cell_log:3):
rtab[0]:=xmit_sz:0 maps[0-7]
rtab[1]:=xmit_sz:8 maps[8-15]
rtab[2]:=xmit_sz:16 maps[16-23]
rtab[3]:=xmit_sz:24 maps[24-31]
rtab[4]:=xmit_sz:32 maps[32-39]
rtab[5]:=xmit_sz:40 maps[40-47]
rtab[6]:=xmit_sz:48 maps[48-55]
New rate table mapping, with kernel cell_align support.
rtab[0]:=xmit_sz:8 maps[0-8]
rtab[1]:=xmit_sz:16 maps[9-16]
rtab[2]:=xmit_sz:24 maps[17-24]
rtab[3]:=xmit_sz:32 maps[25-32]
rtab[4]:=xmit_sz:40 maps[33-40]
rtab[5]:=xmit_sz:48 maps[41-48]
rtab[6]:=xmit_sz:56 maps[49-56]
New TC util on a kernel WITHOUT support for cell_align
rtab[0]:=xmit_sz:8 maps[0-7]
rtab[1]:=xmit_sz:16 maps[8-15]
rtab[2]:=xmit_sz:24 maps[16-23]
rtab[3]:=xmit_sz:32 maps[24-31]
rtab[4]:=xmit_sz:40 maps[32-39]
rtab[5]:=xmit_sz:48 maps[40-47]
rtab[6]:=xmit_sz:56 maps[48-55]
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
Change tc_calc_rtable() to take a tc_ratespec struct as an
argument. (cell_log still needs to be passed on as a parameter,
because -1 indicate that the cell_log needs to be computed by the
function.).
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
The only current user is HTB. HTB overhead argument is now passed on
to the kernel (in the struct tc_ratespec). Also correct the data
types.
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
Hello Stephen,
As the current maintainer of iproute2 package, you could be interested
in including the attached patch that allow using masks in the fw filter
of the tc utility (very useful at least for me). AFAK, it works at least
from iproute2 version 2.6.20-?. Feel free to make the appropriate
cleaning changes if necessary, or contact me if you see any trouble.
Best regards,
François Delawarde.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
tc_core_time2big only used in tc/q_netem.c where it gets passed an unsigned.
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Follow up patch to "Fix overflow in time2tick / tick2time." which switches
the remaining two helper functions from long to unsigned as well.
These functions are only used in "tc/q_hfsc.c" where both the passed argument
and the place the return value is stored are unsigned/u32 variables, so this
change should be safe to make but hasn't been tested as extensively as the
time2tick patch.
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
The helper functions gets passed an unsigned int, which gets cast to long
and overflows. See http://bugs.debian.org/175462
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
The help/usage screen of ematch cmp and nbyte say recognised symbolic
values for "layer FOO" are link, header and next-header, but the code
does _not_ implement that: it will recognise "next-header" as what is
supposed to be "header" and will not recognise "header". The right
symbolic values seem to be link, network, transport. Here is a patch
that changes the help/usage screen to match the code.
(http://bugs.debian.org/438653)
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
em_meta doesn't send 0 values to the kernel. breaking matching on them and
resulting in "Missing value TLV" messages on dump.
Signed-off-by: Patrick McHardy <kaber@trash.net>
This patch applies on top of Patrick McHardy's RTNETLINK
patches to add nested compat attributes. This is needed to maintain
ABI for sch_{rr|prio} in the kernel with respect to tc. A new option,
namely multiqueue, was added to sch_prio and sch_rr. This will allow
a user to turn multiqueue support on for sch_prio or sch_rr at loadtime.
Also, tc qdisc ls will display whether or not multiqueue is enabled on
that qdisc. When in multiqueue mode, a user can specify a value of 0 for
bands, and the number of bands will be created to match the number of
queues on the device.
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the ->dequeue() routine.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
>>That command is from a script that used to work with iproute2-ss020116
>>(2002!), which had the following in tc/m_police.c:
>>
>>210 } else if (strcmp(*argv, "action") == 0) {
>>211 NEXT_ARG();
>>212 if (get_police_result(&p.action, &presult, *argv)) {
>>
>>I don't know when that bit was dropped, but it used to be there. :-)
>
>
>
> Indeed, I missed that. I'll fix up the patch ..
OK this patch fixes parsing of "action ...". I've removed
the erroring on unknown arguments again since in that case
the caller should continue parsing.
>
> Is it a bug that:
>
> # tc filter add dev eth0 parent 1: protocol ip prio 0 handle 0xfffffff
> fw police rate 1 burst 1 mpu 0 mtu 1 action drop
> ^^^^^^^^^^^
> creates a filter that looks like:
>
> # tc filter ls dev eth0
> filter parent 1: protocol ip pref 49152 fw
> filter parent 1: protocol ip pref 49152 fw handle 0xfffffff police 0x1
> rate 0bit burst 0b mtu 1b action reclassify
> ^^^^^^^^^^^^^^^^^
> ref -543190236 bind 4
>
> (which reclassifies and thus lets 0xfffffff-marked packets through).
>
> I'm pretty sure this used to work under 2.4.x (though I no longer have a
> 2.4 box to test with), but it hasn't worked on any of the 2.6.x kernels
> I've tried (with both iproute2-ss060323 and 070710).
Good catch. It seems this is merely a parsing error, iproute doesn't
have an "action" parameter and aborts parsing, so it uses the default
value of "RECLASSIFY". It never had this parameter, so this patch
removes it from the help text and makes it return an error.
Make netem static rather than shared library. It saves problems
on 64 bit platforms.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
This one also makes sense for the release I guess.
-------- Original Message --------
Subject: Re: more iproute2 issues (not critical)
Date: Sat, 31 Mar 2007 16:16:56 +0200
From: Patrick McHardy <kaber@trash.net>
To: Denys <denys@visp.net.lb>
CC: Stephen Hemminger <shemminger@linux-foundation.org>,
netdev@vger.kernel.org
References: <20070321175951.M73913@visp.net.lb>
<46026717.9060909@trash.net> <20070322124533.M79867@visp.net.lb>
<46027FF2.6020001@trash.net> <20070322101224.3e6bb899@freekitty>
<20070331021401.M17326@visp.net.lb> <20070331023011.M8101@visp.net.lb>
Denys wrote:
> Ooops, sorry, it seems my fault, no library exist on this system.
> But i guess it must not coredump in this case? Is it possible to check if
> library not exist and just print some nice message?
> It is trivial i guess.
The problem is that lib_dir is NULL when calling get_target_names.
This patch fixes it.
[IPROUTE]: m_ipt: fix crash when dumping rules
lib_dir is NULL when calling get_target_name, causing a NULL pointer
dereference in the strlen call.
Signed-off-by: Patrick McHardy <kaber@trash.net>
In order to support these new flags add current
linux/if.h into the directory with the local copies.
This caused troubles with outdated redefinitions from net/if.h
so I've removed the dependency on it.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
This reverts fd784ccaf6 commit.
Thanks Stephen, but actually I think the last patch (increase clock
resolution) shouldn't go in yet. I'm not done yet looking at all
the compatibility issues and it does change the range of valid
values for everything dealing with times. Most places I looked
at still accept reasonable ranges, but I would feel more comfortable
to make sure everything is fine first.
> It is in current git tree.
A small fix attached after some testing.
Please dont forget to apply my other patches. When you have them let me
know so i can do some more testing.
cheers,
jamal
[TC] Get iptables path selection to set correct path
A small tweak on top of Stephens patch
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Jesper Dangaard Brouer
Mike Frysinger
Stephen Hemminger
PJ Waskiewicz
Patrick McHardy
Denys Fedoryshchenko
Jesper Dangaard Brouer
Stephen Hemminger
François Delawarde
Herbert Xu
Andreas Henriksson
Lionel Elie Mamane
Thomas Graf
jamal