[LARTC] tcng version 10b
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-10b.tar.gz md5sum d28bc6b1ed8973814213942288ab5d18 See also http://tcng.sourceforge.net/ This release fixes a few compatibility problems with internationalization and with kernels using strange version names. Also, the "mtu" parameter of TBF is now optional. The complete list of changes is below. - Werner --- CHANGES --- - the "mtu" parameter in TBF is now optional - tcsim now uses KVERSION[NUM] instead of KFULLVERSION[NUM] to avoid breaking if EXTRAVERSION contains multiple dots or other surprises (reported by Eduardo Grosclaude) - scripts/runtests.sh now runs commands with LANG=C, to avoid localized error messages (reported by Eduardo Grosclaude) -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 10a
... is on SourceForge:
http://tcng.sourceforge.net/dist/tcng-10a.tar.gz
md5sum 3f58447fdf393cbe3c584d80089806dc
See also http://tcng.sourceforge.net/
This release changes a bunch of things, hence the jump in the
version number:
- the name of the traffic control compiler has changed from
"tcc" to "tcng". This has become necessary because of a
name conflicy with the "Tiny C Compiler". For now tcng uses
both names, but I'll remove the "tcc" part soon.
- tcng and tcsim are now compatible with iproute2 maintained
by Stephen Hemminger. A first consequence of this is that
HTB no longer needs a separate patch. Also supporting other
new traffic control components will be easier by having an
up to date version of iproute2.
- last but not least, tcsim can now use the 2.4.27 kernel
(just in time before 2.4.28 gets released, I know :-)
I didn't go through the whole array of compatibility tests yet,
so there could be problems if you're not using the 2.4.27 kernel
and iproute2-2.6.9-ss040831.
The complete list of changes is below.
- Werner
--- CHANGES ---
- configure is compatible with 2.4.27
- updated kernel version example in README from 2.4.26 to 2.4.27
- scripts/compatibility.sh: added 2.4.27
- changed name of "tcc" to "tcng", for collision with "tiny cc" (reported by
Matthias Urlichs)
- scripts/localize.sh: now installs a wrapper for "tcng", pointing to "tcc"
- scripts/symlinks.sh: now adds a link from "tcng" to "tcc"
- tcsim/tcsim.c: now calls "tcc" as "tcng"
- configure: changed "tcc" to "tcng" at all user-visible places
- tcc/tcc.c: no longer identifies itself as "tcc" when invoked with -V
- Makefile: the binary distribution for "tcc" is now called "tcng"
- build/{tcng,tcsim}.spec.in: changed most references for "tcc" to "tcng"
- Makefile: removed lib/tcng/include/klib/kernel/include from TCSIM_BINDIST
- configure now uses include/SNAPSHOT.h instead of RELNOTES to detect iproute2
version
- configure is now compatible with iproute2-2.6.8-ss040730 and
iproute2-2.6.9-ss040831 (updated tests/cbqroot and tests/tbf)
- tcng/README now recommends to download iproute2-2.6.9-ss040831.tar.gz
(this also affects tcsim.spec)
- recent versions of iproute2 only support MPUs <= 255 bytes (updated
tests/mpu)
- tcng can now use "conform-exceed" instead of "action" (updated tests/drop)
- configure: new options "--action" (or "-a") and "--conform-exceed" (or "-A")
to override action handling
- tcc/Makefile now depends on ../config
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9m
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9m.tar.gz md5sum 636d382f6db917b385e7a6f158136ca2 See also http://tcng.sourceforge.net/ This release contains the upgrade to 2.4.26, plus a few compatibility changes. There's also a major bug that strangely went undetected until recently, when Laurent Moutel reported that his classifiers behaved unexpectedly: if testing fields in a "late" header before testing fields in an "early" header (e.g. TCP port before IP address), the u32 output generated by tcc had the offsets wrong. I didn't have time to properly fix this yet, but tcc now detects this problem, and prints an error message. So if it reports unsupported offset sequence - please try to reorder matches try to make sure that tests connected by && test headers in the order in which the appear in the packet. The complete list of changes is below. - Werner --- CHANGES --- - configure is compatible with 2.4.26 - updated kernel version example in README from 2.4.25 to 2.4.26 - scripts/compatibility.sh: added 2.4.26 - installation example in README now also mentions downloading the iproute2 tarball from Debian - configure and scripts/minisrc.sh now also recognize the Debian iproute tarball - tcsim/setup.klib: added "time_after" and "time_after_eq" to linux/sched.h - tcsim/setup.klib: converts dsfield.h to remove bare newlines from strings (needed to build tcsim with old kernel sources and a new gcc) - if_u32.c:dump_and now checks if any but the last && term changes the offset group (tests/tcng-9m; updated tests/tcng-2i, reported by Laurent Moutel) - tcsim/Makefile: compile tcsim.c without kernel includes, to avoid confusing glibc headers (reported by Nuutti Kotivuori) -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: tcng version 9l
Sorry for not handling this earlier. Been a bit overloaded recently :-( Nuutti Kotivuori wrote: > Which is caused by having klib/include in the include path, and it > overriding what linux/compiler.h is. If I add: > > #define __user > #define __kernel I'd rather try to avoid the problem entirely. Fortunately, we can build tcsim.c without the "kernel" includes. Please try tcng-9m, and holler if it still doesn't work. Thanks, - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9l
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9l.tar.gz md5sum b1dde4ec97fa042d76d498cf87019551 See also http://tcng.sourceforge.net/ Since I cleaned up so many things for Gentoo yesterday, here's one for Debian 3.0. The main problems were: - its CPP doesn't like variadic macros with an empty argument list - its CPP really wants -$, even if -std=c99 is set There was also a race condition beween an exit handler (that had no business being invoked in the first place) and CPP termination in tcsim. Funny that this didn't show up earlier. Last but not least, there was one more 32 bit-ism I hadn't caught yet. The complete list of changes is below. - Werner --- CHANGES --- Version 9l (29-FEB-2004) - configure did not preserve the YACC setting across sessions - configure now complains if -k, -i, -d, -t, or -y have no argument - tcc and tcsim now use -$ if -std=c99 does not work (updated tests/cppdollar) - configure: new options "-$" and "--c99" (or "-c99") to override dollar handling - the writer helper process of tcsim now always exits with _exit, to avoid running the exit handler that kills cpp - runtests.sh converts " parse " to " syntax " in stderr if expecting an error, because some YACCs print "parse error" instead of "syntax error" - examples/prio+fw, examples/tbf, examples-ng/pfifo_fast, examples-ng/prio+fw, examples/priority, tests/idiomatic, tests/packet, tests/tcsattpro, tests/tcsattpsv, tests/tcsattset, tests/tcsdefinc, tests/trace, tests/u32dlb, and tests/u32slb now avoid using variadic macros with an empty argument list all, to keep some versions of CPP from complaining - tests/tcng-7g forced a syntax error at EOF, which yielded inconsistent results with different versions of CPP - updated kernel version example in tcng/README from 2.4.22 to 2.4.25 - q_htb.c: used ~0UL to mean "0xUL" - moved removal of .depend from "clean" to "spotless" make target - tcsim/Makefile: removed left-over dependencies on module cleanup targets "ephemeral-mod" and "clean-mod" - tcsim/modules/Makefile did not define OBJS -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9k
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9k.tar.gz md5sum 330440ac8cd8991fc1a09feacee0612e See also http://tcng.sourceforge.net/ This release addresses various compatibility issues: - compatibility with GCC 3.3.3 - better compatibility with Gentoo Linux - a few general 64 bit improvements and corrections - amd64-specific changes The 64 bit part went surprisingly smoothly. tcc and tcsim now run on amd64, and the regression tests like the new CPU, too. tcng should still work on PPC, but since I don't have a local PPC machine, I didn't test this. Another new feature is that configure's -i option now also accepts a tarball (like -k does). The complete list of changes is below. - Werner --- CHANGES --- Version 9k (28-FEB-2004) - cpp 3.3.3 unceremoniously dropped "-$", so we're now using "-std=c99" (updated tests/cppdollar, tests/phasep) - tcc and tcsim now invoke cpp with argv[0] set to the name of cpp (instead of the name with which tcc or tcsim was invoked), for cpp 3.3.3 compatibility (updated tests/tcng-6u) - POSIX obsoleted "tail -N", using "tail -n N" now (updated tests/tstcond) - Makefile: added remark that the ebuild that comes with tcng isn't nearly as good as the one from Gentoo - build system now uses bison if "configure" finds no yacc - configure: added option --yacc (-y) to set the YACC command - toys/comtc now uses extension .i instead of .cpp, since the latter caused cpp to switch to C++ mode - configure: changed "dir_or_tarball" to "dir_or_tar.bz2" in description of "--kernel" argument - configure now also accepts tarballs for iproute2 - added scripts/minisrc.sh which extracts the files needed to build tcsim from an iproute2 tarball - changed UNDEF_U32 from ~0UL to ~0U for 64 bit compatibility - tcc/ext_io.c:expand_errors added casts to avoid complaints when using a pointer difference in printf on 64 bit - setup.klib: elements of "struct timeval" are now "unsigned long" instead of "unsigned" for better compatibility with glibc on 64 bit - kmod_cc and tcmod_cc now use -fPIC for amd64 compatibility - tcc/ext/Makefile and tcc/ext/tcc-ext-test.in now use -fPIC for amd64 compatibility - tcc/iflib_actdb.c:debug_subtree printed pointer to policier instead of its number - setup.klib: linux/types.h now just #includes stddef.h instead of trying its own definitions for size_t and NULL - changed long obsolete "make upload" to equal "make upload-sf" -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9j
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9j.tar.gz md5sum d0f0b1b20a6711f447d5321138ab5852 See also http://tcng.sourceforge.net/ This is a maintenance release that mainly synchronizes with current 2.4 kernels. The complete list of changes is below. - Werner --- CHANGES --- Version 9j (26-FEB-2004) - Makefile: targets "tcc" and "tcsim" depend also on "shared" (reported by Mustafa Ogun) - configure is compatible with 2.4.24 and 2.4.25 - scripts/compatibility.sh: added 2.4.23, 2.4.24, and 2.4.25 - minksrc.sh now only extracts kernel source from tarball if the source has not already been extracted - moved progress reporting from "configure" to "minksrc.sh" - "make clean" now also removes temporary files of "configure" -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9i
... is on SourceForge:
http://tcng.sourceforge.net/dist/tcng-9i.tar.gz
md5sum 50f497a7539e4c03c5783b410b132127
See also http://tcng.sourceforge.net/
Highlights:
- added support for TBF with an inner queuing discipline
(Kernel >= 2.4.22 or >= 2.5.75. iproute2 doesn't change.)
- added an ebuild script for Gentoo (contributed by "raptor")
- cleaned up the tcsim build process a little and added a script
that runs all regression tests involving tcsim on all supported
kernels
Here's an example for the new and improved TBF:
tbf (mtu 1.5kB,limit 10kB,rate 1kBps,burst 2kB) {
fifo;
}
(Since TBF doesn't really have classes, tcng won't let you try to
specify one. Internally, it adds a class, which is also visible
at the external interface.)
The complete list of changes is below.
- Werner
--- CHANGES ---
Version 9i (22-NOV-2003)
- tcc now supports TBF with an inner qdisc (tests/tbfqdsyn, tests/tbfqdtc,
tests/tbfqdext, tests/tbfqdrun)
- removed redundant flag QDISC_HAS_DEFAULT
- added build/tcng.ebuild file for Gentoo (by "raptor")
- Makefile: added "gentoo" target
- setup.klib no longer uses a symbolic link to the original source tree
- configure: added option --no-defaults to skip loading of old config file
- tcsim/Makefile.unclean tcsim/modules/Makefile: object files now depend on the
config file
- added scripts/minksrc.sh which extracts the files needed to build tcsim from
a kernel tarball
- added scripts/compatibility.sh which runs all regression tests involving
tcsim for all supported kernel versions
- Makefile: added "compatibility" target
- "make sf-upload" now prints the MD5 message digest before uploading
- configure: removed 2.4.11 kernel, which was withdrawn
- configure: -k argument can be a kernel tarball
- runtests.sh: added option -t to run only tests probably using tcsim
- setup.klib: unconditionally defining LONG_MAX in include/linux/kernel.h broke
2.5.4 builds
--
_________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9h
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9h.tar.gz md5sum 9b7c520f92b312a5a00da12bad35f57d See also http://tcng.sourceforge.net/ This release upgrades to the current 2.4 kernels, fixes a few minor glitches in the build system, and adds the options --no-manual and --with-manual to configure, so that tcng can be build without the documentation (also, configure uses --no-manual if it can't find latex or dvips). The complete list of changes is below. - Werner --- CHANGES --- Version 9h (7-NOV-2003) --- - tcc/ext/Makefile: dependencies now only include .c files compiled in that directory, removing a warning when building RPMs - split tcsim/Makefile into Makefile.unclean and Makefile.clean to avoid rebuilding klib and ulib when cleaning up after configuration changes - configure is compatible with 2.4.22 and 2.4.23 (pre-release, tested with 2.4.23-pre9) - setup.klib generates linux/smp.h needed for 2.4.22 - tcsim/trace.c and tcsim/modules/sch_discard.c adjust ..._drop prototype for interface change in 2.4.22 - setup.klib clears LANG before using sed on [^ -~] - setup.klib adds "err" and "error_report" members to "struct sock" in af_netlink.c (for 2.4.23) - updated kernel version example in tcng/README from 2.4.21 to 2.4.22 - configure: added options --no-manual and --with-manual (abbreviations -m and -M) to allow building tcng with or without the documentation (suggested by "raptor") - configure: automatically assumes --no-manual if either latex or dvips is not in the PATH -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9g
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9g.tar.gz md5sum 63ef58e3d3c2cf5298524fb174168681 See also http://tcng.sourceforge.net/ Yes, it's been an eternity since the last release, sorry. I'm obviously having too much fun with umlsim :-) This one starts a round of catch-up releases by fixing a few minor bugs. The next release will add compatibility with more recent 2.4 kernels (of course, tcc should also work on 2.5/2.6), and then there will be one with some new stuff I've accumulated. The complete list of changes is below. - Werner --- CHANGES --- Version 9g (6-NOV-2003) --- - tcsim leaked memory for variable names (fixed by Dimitry Ketov) - tcsim now frees commands after execution (based on a patch by Dimitry Ketov) - tcsim -c freed command variables on each access (tests/tcng-9g) - scripts/runtests.sh: the -c option had no effect and was not mentioned in the usage - changed "tree color meter" to "three color meter" in documentation (fixed by Martin A. Brown) -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9f
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9f.tar.gz md5sum 28ff5fdd6e63ef1895728d20f660f0a1 (See also http://tcng.sourceforge.net/) This just is the upgrade for 2.4.21-final compatibility. It also fixes some things that broke tcsim builds with some old kernels. The complete list of changes is below. - Werner --- CHANGES --- Version 9f (19-JUN-2003) - updated kernel version example in tcng/README from 2.4.20 to 2.4.21 - setup.klib is now compatible with 2.4.21 (final release) (by Dimitry Ketov) - fixed setup.klib compatibility with old kernels, like 2.4.3 -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Re: [patch] setup.klib (tcng-9e) patch for linux-2.4.21 changes
Dimitry V. Ketov wrote: > Some things were changed in recent 2.4.21 kernel, so here is the patch > for tcng-9e, if you're interesting in. Thanks a lot ! I'll make a new release of tcng soon. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tcng and network processor
Chris Clark wrote: > I am considering a project to translate tcc output (C code or external > interface) to network processor code, so that the NP can do the actual > traffic shaping. As Jacob has pointed out, tcc's external interface is what you're looking for. > I have a platform using the Intel IXP1200 NP on a PCI > card, which functions as a NIC for the host PC running Linux. This > approach would reduce the processing load on the host. It's about time somebody tackles the Intel NPs :-) Actually, it would be good if - provided you get this project rolling - you could find a way to get Intel to let you release your code generator. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] classes on several interfaces at once ?
raptor wrote: > is it possible with the tcng-macros or something else to make classes > in such a way so that I write them once and set simultaneously classes > on many interfaces.. what i mean , something like this : Well, probably :-) It's up to you do decide how much time you want to spend on some intricate macro hack, or if you want to write a script that generates full or partial tcng output instead. While it can be fun to create something exceedingly complicated in cpp (try meters.tc for a taste), you have to consider that time_spent = O(something^complexity) :-) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] the difference ?!
Whoops, haven't checked LARTC in a while ... raptor wrote: > what is the difference between : > > police(), bucket(...) and SLB(..)/DLB() and friends ?! "police" refers to the policing component of the traffic control subsystem in the kernel. "bucket" (with the "conform" and "count" operators) is an abstracted single bucket. If you actually use it, and you're generating "tc" output, tcc will express its function in terms of "police". SLB, DLB, etc. are basically expressions that use buckets. Again, tcc will (try to *) express them using "police", plus some classification tricks. (*) Buckets can be used for arbitrary constructs that exceed what can be done with the policing mechanisms of kernel traffic control. The "dictionary tcc uses is in tcc/if_u32.c:map Think of it as "police" being a pocket calculator, "bucket" being the basic arithmetic operations, and SLB, etc. being some common formulas, like the compound interest formula. If presented with such a formula, tcc will then know which buttons to press on the pocket calculator. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9d
... is on SourceForge: http://tcng.sourceforge.net/dist/tcng-9d.tar.gz md5sum 0f61201c657f1851d9d12ca897a4985e (See also http://tcng.sourceforge.net/) This is a maintenance release that fixes various compatibility problems. It also recognizes more recent kernels. The complete list of changes is below. - Werner --- CHANGES --- Version 9d (14-JAN-2003) - updated kernel version example in tcng/README from 2.4.19 to 2.4.20 - configure is now compatible with 2.4.21 (pre-release, tested with pre3) - tcsim -V now also prints the versions of the kernel and iproute2 used to build it - make "upload-sf" now runs md5sum after uploading - README: changed tar xfI to more compatible bzcat | tar xf - - generalized argument-fetching mechanism of sprintf, and split it into sprintf.c and sprintf_generic.c - removed extra % from sprintf's precision error message (updated tests/sprintf) - comtc's second pass now invokes tcc with the -n option, because some versions of CPP don't allow -include with -fpreprocessed - toys/comtc mis-converted stdin location tags when using cpp 2.96 (reported by Martin A. Brown) - tcsim executed original rtnl_close, closing an undefined file descriptor, which sometimes upset flex, causing it to fail with "input in flex scanner failed" (reported by "bauer") -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tcng 9b tests error
[EMAIL PROTECTED] wrote: > I was trying out tcng and got the following error. Any suggestions? Yech, found it at last. I missed rtnl_close, which closen an undefined file descriptor, which just happens to be zero on RH 7.3, which in turn upsets flex. Will be fixed in version 9d. Thanks, - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tcng compile problem
Kreso wrote: > make[3]: Entering directory /home/kreso/tcng/tcsim/ulib/iproute2/lib' > gcc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations > -I../shared -Iklib -Iklib/include -Iulib/iproute2/include -I. > -DVERSION=\"cat ../VERSION\" -DTOPDIR=\"/home/kreso/tcng\" > -DTCC_CMD=\"/home/kreso/tcng/bin/tcc\" -c -o libnetlink.o libnetlink.c > cat: ../VERSION: No such file or directory > libnetlink.c:13:24: libnetlink.h: No such file or directory This looks very weird. What kind of make (make --version) are you using, and from which distribution does it come ? - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9c
... is on SourceForge, http://tcng.sourceforge.net/#src The increasingly more mis-named if_u32 can now also build classifiers using the meta fields meta_nfmark and meta_tc_index. (Yes, finally !) There was also a rather serious bug in the generation of multi-phase policers (i.e. what if_u32 uses for srTCM, trTCM, and similar), which caused rules to be emitted in the wrong order. Phases are now handled implicitly in the action and match dumping functions, which use a stack of rules leading to the current decision. While this change doesn't quite make if_u32 look pretty, it's at least a bit less obscure now. Another bug that has evaded detection for a surprisingly long time was that invalid digits (i.e. 8 or 9) in octal numbers caused tcc and tcsim to silently ignore the rest of the number. There were some more minor corrections and improvements. The complete list of changes is below. - Werner --- CHANGES --- Version 9c (14-NOV-2002) - if_u32 badly mis-ordered rules with multi-phase policers (tests/u32pol) - updated tests/arith, tests/egress, tests/intro, tests/selpath, tests/selpathcbq, tests/selpathdup, tests/selpathgred, tests/tcng-2n, and tests/tcng-7o to use unified match format introduced with above fix - tcc and tcsim silently ignored invalid digits in octal numbers (tests/tcng-9c) - tcsim did not report EOF in tcng section as an error (tests/tcng-9c) - updated tests/typerr and tests/varhash accordingly - if_u32.c can now generate fw and tcindex classifiers from meta-fields (tests/metau32) - for consistency, dsmark can now also default parameter "value" from qdisc (tests/u32pol) - tests/tcstimstp used packets that caused SFQ to segfault under efence - scripts/runtests.sh: also "comtc" now filters efence blabber - added known range check problem to TODO -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] can anyone help me to solve this problem?
Folke Aeon wrote: > it works currently, but wonder whether there will be > any negative influence or not. would you please give > some comment on this ? It should work. You just have to be aware that your kernel is doing some odd things ... > another thing, i noticed that since the dsmark dequeue > function does not support mpls protocol, so when a mpls > packet arrives, it complains "unsupported protocol". Only if you try to change the DS field. > Although the tcindex value is still there, it just cannot > use it . i think this is where the problem lies in. No. tc_index does not have to equal the DSCP or DS field. In dsmark, tc_index is an index to a table with DS field changes. All you need to do is to reserve a tc_index value for non-IP traffic, and only mark IP traffic with other values than that. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] can anyone help me to solve this problem?
Folke Aeon wrote: >can IMQ classify packets based on their RATE and BURST ? > if it cannot , then it wouldn't do any help to me . :( I haven't used IMQ myself, but I'd expect it to work with policing, etc., like everywhere else, yes. >>(Well, or fix MPLS to preserve skb->tc_index.) > > to be frank i am not quite familiar with this stuff. > i just do everything according to the installation guide > shipped with the mpls-patch downloaded at sf.net/mpls-linux/ :( I suppose, on http://lists.sourceforge.net/lists/listinfo/mpls-linux-general they could help you, if you described the problem. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] can anyone help me to solve this problem?
Folke Aeon wrote: >well , would you please tell me where should i > add these ? In your tcng configuration file. Of course, if you like things a bit more cryptic, you can also try to do this with plain u32 :-) - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] can anyone help me to solve this problem?
Folke Aeon wrote: > i still want to know whether i can mark the > dscp at the ingress qdisc or not No, you can't. You might be able to perform the same classification at egress, though. If all else fails, you might be able to accomplish some marking based on ingress decisions with IMQ. (Well, or fix MPLS to preserve skb->tc_index.) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] can anyone help me to solve this problem?
Folke Aeon wrote: > BUT my trouble is , since i also use have to > direct all packets into mpls layer , i cannot > do the dscp marking at the egress . because > the mpls header is added at the step immediately > after the packet passes through system routing > table. You can explicitly classify on the DSCP, i.e. without using tcindex. If you need to explicitly skip the MPLS header, you may use a construct like this: field mpls_hdr = raw if meta_protocol == ETH_P_MPLS; /* or whatever */ field ip_hdr = mpls_hrd[4]; /* skip shim header */ ... do_whatever if ip_dscp == some_value; ... > on the packet. i cannot setup proper filter > based on the index value marked at the ingress. > thought i still not quite sure whether it is > because of the mpls header that influences my > purpose, That's odd, yes. If MPLS clears skb->tc_index, that would be a bug. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] is this a bug?
Folke Aeon wrote: > i turned the SMP off , and everything is ok now. :) Argh, for some definition of "ok" :-) Okay, this needs to be looked into, thanks ! - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] is this a bug?
Folke Aeon wrote: > i do the following on my linux, Which kernel ... ? SMP or not ? CONFIG_PREEMPT set ? At least 2.5.44, neither SMP not preempt, didn't do anything funny when I tried this. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] does any body ever met this strange problem?
Folke Aeon wrote: > hi, does any body ever met this strange problem? No, I haven't, because I usually don't nest dsmark ;-) dsmark changes the DS field according to the value in skb->tc_index when the packet _leaves_ the qdisc, and your inner dsmark changes skb->tc_index. I suggest you have a look at figures 6 and 8 (the latter is on page 6) of ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9b
... is on SourceForge, http://tcng.sourceforge.net/#src This one fixes a really stupid typo causing tcsim's tc to pick up HZ from the environment where it's being run, not the simulation environment, which confused most rate calculations. And if_u32.c now only emits hashes that will actually be used, which should make tcc's tc output a little less ugly. Complete list of changes below. - Werner --- CHANGES --- Version 9b (21-OCT-2002) - tcsim tried to ignore system HZ (tc/tc_core.c:tc_core_init), but didn't - test "SLB with MPU (ext)" actually used tc, not the external interface (tests/mpu) - added dependency on ../VERSION for tcc.o and tcsim.o - if_u32.c now generates hashes only if they are actually referenced - updated tests/cbqroot, tests/comtc, tests/egress, tests/htbng, tests/intro, tests/selpath, tests/selpathcbq, tests/selpathdup, tests/selpathgred, tests/tcng-2h, tests/tcng-2i, tests/tcng-2j, tests/tcng-2q, tests/tcng-3g, and tests/tcsenq accordingly -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Problems patching kernel 2.4.19-r9
[EMAIL PROTECTED] wrote: > could I simply use the earlier version of HTB (HTB2 ?) > which is already in the 2.4.19-9 kernel I have > installed? I don't know about 2.4.19-9, but if you use 2.4.20-pre6 or newer, the procedure is as follows: $ wget http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz $ tar xfz iproute2-2.4.7-now-ss010824.tar.gz $ mkdir htb $ tar xCfz htb htb3.6-020525.tgz $ patch -s -p1 -d iproute2 http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 9a
... is on SourceForge, http://tcng.sourceforge.net/#src
This time, there's only some maintenance: some bug fixes, and
now also the "C" and "external" targets support classification
by protocol. This means that I'll now be able to use trinity.sh
to test classification by meta field, which will be useful for
experimenting with more complicated expressions.
Note that the tccext API has changed: meta fields are now
accepted, and indicated by the offset group pointing to
&tccext_meta_field_group.
The complete list of changes is below.
- Werner
-- cut here ---
Version 9a (18-OCT-2002)
- iflib_not.c:single_bit_test failed an assertion when comparing 128 bit
values (tests/tcng-9a, reported by Jacob Teplitsky)
- shared/addr.c:ipv{4,6}_host now cache query results in order to avoid
inconsistencies when external database changes during tcc run
- updated TODO accordingly
- added top-level Makefile target "count-tests"
- top-level Makefile targets "test", "tests", and "valgrind" weren't .PHONY
- "c" target did not detect unsupported field roots (tests/tcng-9a)
- "c" target now supports the "protocol" meta field (tests/protc)
- renamed meta.h to tccmeta.h and added it to tcc's public include files
- added support for meta-field to external interface (tests/protext)
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng: overview paper
I just uploaded a slightly updated version of the tcng overview paper I presented last month at Linux-Kongress in Cologne: http://tcng.sourceforge.net/doc/tcng-overview.ps There are also links to a PDF version and the source from http://tcng.sourceforge.net/ - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Re: LARTC digest, Vol 1 #818 - 8 msgs
[EMAIL PROTECTED] wrote: > > From: Pedro Larroy <[EMAIL PROTECTED]> >> It's better to change /usr/src/linux/include/net/pkt_sched.h >> PSCHED_CLOCK_SOURCE to PSCHED_CPU if you have a cpu with timestamp >> counter (TSC) that will give you Mhz timer granularity. Unfortunately, only time measurement will be improved, not timer resolution. So TBF etc. will still burst at HZ. > would you please tell me how to check out whether > my cpu has a TSC or not ? grep -w tsc /proc/cpuinfo - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] exceeding child bandwith only in special cases ?
raptor wrote:
> i.e only when class1 bandwith is exausted and the traffic is destinated
> to proxy give another 64kb/s. (if not exhausted use it, if exausted but
> not destinated to proxy then sorry)
First of all, this has not all that much to do with classes,
because metering receives no feedback from queuing. But you
can of course try to build a system without feedback.
> I know that it can possibly be achieved with the Metering
> primitives, but can figure it out yet.. could u help me..
For tcc, that's pretty straightforward, e.g. something like
this:
$low = bucket(rate 64kbps,burst 30kB);
$high = bucket(rate 128kbps,burst 30kB);
$cond = ip_src == 192.168.0.1;
$is_proxy = ip_dst == 192.168.0.15;
egress {
class (<$good>)
if $cond && $is_proxy &&
conform $high && count $low && count $high;
class (<$bad>)
if $cond && $is_proxy;
class (<$good>)
if $cond &&
conform $low && count $low && count $high;
class (<$bad>)
if $cond;
class (<$bad>) if 1;
prio {
$good = class;
$bad = class;
}
}
(For real-life use, you'd probably want to put these meters
in macros, like trTCM and friends.)
Now, this is a metering configuration tcc doesn't understand
yet, so you need to add the following rules to if_u32.c:map:
/* raptor's VIP band */
{ "n0t0t1c2c3", "p0uc3 p1uc2 c2" },
{ "n0t1t0c2c3", "p0uc3 p1uc2 c2" },
{ "n0t0t1c2d", "p0ud p1uc2 c2" },
{ "n0t1t0c2d", "p0ud p1uc2 c2" },
(You need the last two if you want to drop instead of using
a "bad" class. And, BTW, why "... p1c2c2" instead of
"... p1uc2 c2" wouldn't work is left as an exercise to the
reader :-)
All this is, of course, completely untested.
> One other question in this case should classes be parent and child i.e.:
There's only one class for both types of traffic :-)
- Werner
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tcng version 8z
raptor wrote: > now that the alphabet has finished what next :") I'll reset the letter and increment the number, so the next version will be "9a" :-) There isn't really all that much meaning in those version names, although I usually try to avoid major destabilizing changes towards end-of-the- alphabet releases. The next things we'll see in 9* are the completion of meta data classification for "tc", and caching for lookups in external databases (see TODO). Then, I want to make iflib_fastbit.c usable, and then being fading out all the other junk in iflib_*. With a little luck, I'll also figure out how to turn "." into an operator. Last but not least, umlsim will eventually replace tcsim, but that's still a bit in the future. >... u can borrow from cyrilic alphabet so that u can have 3 more versions :")) Thanks, I'll remember that when I run out of numbers :-) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] A beginner
Emmanuel SIMON wrote: > Especially, I am looking for the definitions of classes, queues, filters and > so on... You may find ftp://icaftp.epfl.ch/pub/people/almesber/pub/tcio-current.ps.gz useful. It explains mainly implementation details, but also covers the general framework. A more recent, but not quite finished version of this document is in ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8z
... is on SourceForge, http://tcng.sourceforge.net/#src Besides a bunch of bug fixes, this release also contains a greatly improved version of the comtc utility that copies comments from the tcng source to tcc's "tc" output. There are a few infrastructure changes to make comtc work smoothly: - tcc's -E option is now called -Wexperror or -Wexppostopt, respectively - tcc has a _new_ -E option that makes it behave much like gcc -E - tcc also has a new option -f that is used to override the input file Some of the bug fixes are also significant: - if_u32.c sometimes generated incorrect classifiers when using meta fields (disabled by default) - tcc and tcsim happily copied all file name arguments to cpp, which would then equally happily overwrite the second file Also, tcsim's "end" command now checks if there are any polled devices with pending packets, and prints an error in this case. The full change log is below, as usual. By the way, there are now more than 1500 regression tests. - Werner -- cut here --- Version 8z (10-OCT-2002) - tcc and tcsim allowed passing more than one file name to cpp, which treats the second file name as output file (tests/tcng-8z) - protocol support for u32 mis-attached subexpressions under new field root (tests/protcomb) - tests/htbquant and tests/tcstimstp did not probe if HTB is available before using it - tcsim stopped HTB timers before last packet was sent (tests/tcstimstp) - tcsim now detects stopped devices with packets pending at "end" (tests/tcstimstp) - updated tests/basic, tests/tcssnap, tests/u32dlb, and tests/u32slb according to above change - -Wexpensive did not warn about implicit negation (tests/tcng-8z) - tcc: replaced -E with -Wexperror, and -E -E with -Wexppostopt (tests/newexp) - updated tests/bitfield, tests/bittest, tests/expensive, tests/ne, tests/tcng-5y, and tests/tcng-7a according to above change - tcc -E now runs cpp without any further processing (just like gcc -E; tests/tccin) - tcc: added option -f infile to read from specified file, ignoring input file argument (tests/tccin) - tcc now writes location map after dumping, in order to include target-specific fixups in map - added script toys/comtc that copies comments immediately preceding elements to tc output (tests/comtc) - runtests.sh: added command comtc to invoke toys/comtc - tcc sometimes forgot that "prio" qdisc now supports policing (tests/tcng-8z) - cleaned up hack causing compiler warning in if_u32.c -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] FIXME:tc crashes when dsmark root qdisc deleted
amit jaiswal wrote: > DEV=dev\ eth0 [...] > tc qdisc del dev eth1 root handle 1:0 Is this really what you used ? If yes, what is configured on eth1 ? (I ran a few variations of this through tcsim+valgrind, and it didn't act up.) > the kernel crashes. > The kernel debug messages upto this stage were(using dmesg utility) Nothing about the actual oops ? Can you please run the entire dmesg output through ksymoops ? > If its an error in the command then HOWTO delete the queing discipline when > dsmark is used as its the root qdisc with no associated class # tc qdisc del dev whatever root should be sufficient. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can't keep up with all these file sharing programs!
Jason Tackaberry wrote: > In theory, this scheme works pretty good. The problem is that every day > some of these p2p programs are using different ports, So why don't you just turn the classification around and put everything you know to be "good" in the guaranteed class and all the rest in the junk class ? > Now it would be _really_ nice if there was some ability to examine > packets at layer 7 to determine what class a particular session belongs > in (like, for instance, the way Packeteer's Packet Shaper works). I'm > assuming I can't get this functionality (unless I write it myself), I suppose something along the lines of a transparent proxy would work, but I don't know where you'd find a program that implements the kind of classification you need. > adjustment I can make? Or, perhaps I should try a different approach, > and give each IP a guaranteed rate? The only drawback I see with this > is that with 50 users, I could only guarantee each user 5kbps. :) You could give them equal (RR) shares per IP, with CBQ or HTB. That won't help against distributed downloads (e.g. one downloader using several people's PCs), but it should buy you some time for implementing the L7 solution :-) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] tcc specify device
raptor wrote:
> m'I mistaken ?
Fortunately, yes ;-) There are even two ways:
tcc -i ppp0
fifo;
^D
or
dev "ppp0" {
fifo;
}
- Werner
--
_________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] kernel debugger for RH 7.3
Daniel Sullivan wrote: > I would like to step through the kernel and modules that perform traffic > control. Depending on what you plan to do, you may find tcsim a more convenient tool than a kernel debugger. tcsim runs most of the traffic control subsystem in user space, so you can just use gdb or any other debugger. tcsim is part of tcng, http://tcng.sourceforge.net/ - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tctree + tcng
raptor wrote: > OK, now it should support the output of the tcng too Cool. I like -f comment. Of course, people really ought to format their tcng source such that it's actually readable ;-)) BTW, I'll drop the pragma variant (too awkward), but include an improved version of com.pl in the next version of tcng, along with preprocessing support in tcc. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] and iptables
raptor wrote:
> As we discused earlier in the list tcng still doesn't support
> ipchains/iptable/ip route marking and classifing based on this.
Well, you can just use the MARK target to set skb->nfmark with
iptables, and you can then use this for classification with the
"fw" classifier, e.g.
prio {
fw {
class (1) on (13);
class (2) on (42);
}
}
13 and 42 are the MARK values.
> In fact it a litle bit harder :
> 3 frame realy channels (1 upstream/pvc0 and 2 downstream/pvc1,pvc2) and 2
> eth.
Combining classifiers is rather tricky, and it's also quite
limited by the way how classifiers are chained. You can build
interesting things with that, as shown e.g. in the section
"Dump actions" of tcc/if_u32.c, but it's quite messy.
tcc doesn't support any combined classifiers (when using tc),
because the limitations imposed by the kernel traffic control
are just too narrow.
Example: let's assume, you could select "nfmark == X" in an
"if" construct, and tcc would build a classifier combining
"fw" and "u32". Then, the following expressions could be
converted:
class (<$class_1>) if nfmark == VALUE_1 && $condition_1;
class (<$class_2>) if nfmark == VALUE_1 && $condition_2;
class (<$class_3>) if 1;
and
class (<$class_1>) if nfmark == VALUE_1 && $condition_1;
class (<$class_2>) if nfmark == VALUE_2 && $condition_1;
class (<$class_3>) if 1;
but not
class (<$class_1>) if nfmark == VALUE_1 && $condition_1;
class (<$class_2>) if nfmark == VALUE_2 && $condition_2;
class (<$class_3>) if 1;
I don't even want to think about how to combine this with
policing :-)
So in your case, the correct solution is to do the whole
classification process in iptables, and only use "fw" in
the tcng part. In a future version of tcc, you'll also be
able to usw "if" instead of "fw".
- Werner
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] tcc->tc comments
raptor wrote:
> is there a way so that I can write something like that :
Hmm, looks like a good use for pragmas with tc output ;-)
After applying the attached quick and dirty patch, this
htb (pragma "#the_outer_qdisc") {
class (rate 10kbps,ceil 20kbps,pragma "#the_first_class") {
fifo(pragma "#the_inner_qdisc");
}
}
yields this:
# the_outer_qdisc
tc qdisc add dev eth0 handle 1:0 root htb
# the_first_class
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1250bps ceil 2500bps
# the_inner_qdisc
tc qdisc add dev eth0 handle 2:0 parent 1:1 pfifo
Note that you can't include spaces in pragams, but all other
non-blank characters are fine.
> And similar thing for filters/classifiers ?!
Works there too, but only if using "on". When using "if", tcc
may transform the expression quite heavily, and there's no way
for associating output items with input items (in the general
case).
But a better way to do all this is to use tcc's location map
to extract the comments directly from the source, as demonstrated
by the Perl script in the second attachment.
Input example:
/* this is the comment
for HTB */
htb {
// another comment, this
// time for a class
class (rate 10kbps,ceil 20kbps) {
// last but not least, a comment for the FIFO
fifo;
}
}
Not that, when invoking com.pl, the name of the input file
must be the last command-line argument.
- Werner
--
_________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
--- tc.c.orig Thu Sep 26 17:32:47 2002
+++ tc.cThu Sep 26 17:37:52 2002
@@ -237,6 +237,18 @@
void tc_pragma(const PARAM *params)
{
-if (prm_present(params,&prm_pragma))
- yywarn("\"pragma\" parameter ignored by \"tc\" target");
+const DATA_LIST *pragma;
+
+if (!prm_present(params,&prm_pragma)) return;
+for (pragma = prm_data(params,&prm_pragma).u.list; pragma;
+ pragma = pragma->next) {
+ const char *s;
+
+ s = pragma->ref->u.string;
+ if (*s != '#') {
+ yywarn("\"pragma\" parameter ignored by \"tc\" target");
+ return;
+ }
+ printf("# %s\n",s+1);
+}
}
#!/usr/bin/perl
sub emit
{
return unless $in =~ /\n$_[0] /s;
($s = "\n$`") =~ s/\n\d+ /\n/gs;
return unless
$s =~ m#/\*\s*(([^*]|\*[^/])*)\*/[^\n]*$|//\s*(([^\n]*\n\s*//)*[^\n]*)$#s;
($s = defined $1 ? $1 : $3) =~ s/\n\s*/\n# /sg;
$s =~ s#\s*//\s*# #;
print "# $s\n" || die "stdout: $!";
}
open(FILE,$ARGV[$#ARGV]) || die "$ARGV[$#ARGV]: $!";
while () {
$in .= "$. $_";
}
close FILE;
print "out: $in\n";
open(PIPE,"tcc -l $$.out ".join(" ",@ARGV)."|") || die "tcc: $!";
@out = ;
close PIPE;
exit $? if $?;
open(FILE,"$$.out") || die "$$.out: $!";
for () {
$q{$1} = $2 if /^qdisc [^:]+:(\S+) .* (\d+)$/;
$c{$1} = $2 if /^class [^:]+:(\S+) .* (\d+)$/;
}
close FILE;
unlink "$$.out" || warn "unlink $$.out: $!";
for (@out) {
&emit($q{$1}) if /^tc qdisc .* handle (\d+):0/;
&emit($c{$1}) if /^tc class .* classid (\d+:\d+)/;
print $_ || die "stdout: $!";
}
Re: [LARTC] txqueuelen in ifconfig and tc
Jonas Lindqvist wrote: > Is this queue affected by tc or is it after all shaping? tx_queue_len provides default values for the queue size in all FIFO qdiscs, and an in unconfigured GRED (which acts just as a pfifo)), In HTB, it sets the limit of the queue of class qdisc:0, so it affects traffic that doesn't get shaped. In any case, any additional queuing after traffic control is at the discretion of the network interface driver, and not affected by tx_queue_len. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8y
... is on SourceForge, http://tcng.sourceforge.net/#src
The main changes are that tcng's HTB is now better at quantum
handling, and that tcsim now includes packet.def and ports.tc
automatically (via the new default.tcsim), like tcc uses
default.tc. The full change log is below, as usual.
The HTB change adds a very natural way for expressing a quantum:
instead of the somewhat obscure r2q, the quantum can be specified
as the time during which the class may monopolize the link.
The following two examples are equivalent:
htb {
class (rate 1Mbps,quantum 1250B);
}
htb {
class (rate 1Mbps,quantum 10ms);
}
A larger example for HTB with tcng is at the end of tests/htbng
I still owe you the completion of protocol-aware classification.
Well, next week :-)
- Werner
-- cut here ---
Version 8y (21-SEP-2002)
- HTB quantum can now be specified in bytes or seconds (tests/htbquant)
- documented various parameter handling differences between tcng and tc
- added first example from HTB documentation to tests/htbng
- tcsim now uses default.tcsim to automatically include packet.def and
ports.tc, similar to how tcc uses default.tc (tests/tcsdefinc)
- tcsim: added option -n to disable inclusion of default.tcsim
(tests/tcsdefinc)
- updated tests/cbqroot, tests/cpp31, tests/defcbq, tests/defdsm, tests/ext,
tests/idiomatic, tests/tcng-2j, tests/tcng-3i, tests/tcng-3t, tests/tcng-4n,
and tests/trace to either invoke tcsim with -n, or to avoid using ip.def
- removed use of ip.def from all examples (examples/*, examples-ng/*)
- tcc/defaults.tc now resets the line number in order to work around strange
cpps that embed -included file instead of including it, causing line numbers
to be off by the length of the -included file (reported by "raptor")
- tcsim now stops SFQ and HTB timers at end (tests/tcstimstp)
- updated examples/sfq and examples-ng/sfq accordingly
- moved helper functions alloc, alloc_t, stralloc, and alloc_sprintf to
tcng/shared/memutil.*
- added %c format to alloc_sprintf
- removed potential buffer overruns in tcsim/module.c and tcsim/cfg.l by using
alloc_sprintf
- tcc did not complain when specifying "limit" in bytes and in packets for FIFO
qdisc (tests/tcng-8y)
- added awk to build prerequisites
--
_________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc/htb still hangs system - ksymoops traced.
Tomasz Wrona wrote: > OK, I retyped screenshot and put it to ksymoops and it said: > [Will it be enough info to debug, what can I do also ?] I guess Martin could figure it out from this. I'm too lazy ;-) But it would be interesting to see whether this problem also shows up in tcsim (then, it should be easy to diagnose it completely). You seem to have a sequence of configuration commands that reliably cause this crash, right ? If yes, it would be good if you could send them. Also, do you know what happens at the time of the crash ? Is this simply the first packet that hits HTB after some change, or is this a packet with special characteristics ? (Specific flow, etc.) - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk)
raptor wrote:
> |#line 1
> ]- definetly helps,..
Finally !! The workaround will be in 8y.
> 'man u have put hell-of-a-tests, no bug can escape :")
And then, they mutate ... :)
> check syntax of examples-ng/ef-prio: PASSED
> Standard error:
> | warning: real MTU (guessed 1510) may be larger than 1500
Those MTU warnings are normal, although I should probably get
rid of them eventually.
> SLB without MPU (ext) : PASSED
> SLB with MPU (ext): FAILED
Hmm, that one is a bit surprising ... can you please try the test
with the following changes:
| $p = SLB(cir 500kbps,cbs 3kB);
-- (mpu removed)
| every 0.01s send 0 x 2500 /* 1 Mbps */
(2500 instead of 1250)
> GNU CPP version 2.96 2731 (Mandrake Linux 8.2 2.96-0.76mdk)
Looks like the same version of cpp as used by Red Hat. Odd ...
- Werner
--
_________
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8x
... is on SourceForge, http://tcng.sourceforge.net/#src There's a lot of stuff in this one, and there's even more to come. In fact, the change log just got so long that I need to make this release now :-) Highlight: - added Jacob Teplitsky's HTB for tcng - tcsim's attribute handling got a little smarter again - build/cleanup process housekeeping - lots of minor bug fixes The full change log is below. The probably most interesting feature is Jacob's HTB interface for tcng. Thanks, Jacob ! There are still a few things in parameter handling that may change in the next version of tcng, mainly concerning quanta, but besides that, this looks good. See tests/htbng for an example and its translation. The tcsim attribute handling changes are mainly an extension to allow macros like IP_PCK and IP6_PCK to change the protocol, but in such that this doesn't get in the way with explicitly setting the protocol attribute. The gory details are explained in the tcsim documentation (the "send" command), and in tests/tcsattset and tests/tcsattpro There's also one more user-visible change: the "protocol" attribute is now preserved across links in tcsim, because this is also what's likely to happen in real life. Note that I didn't have time yet to resolve the pending issues in protocol-aware classification. - Werner -- cut here --- Version 8x (20-SEP-2002) - tcc: added HTB queuing discipline (tests/htbng, by Jacob Teplitsky) - tcsim no longer resets the "protocol" attribute when traversing a link (tests/tcsattpsv) - tcsim attributes now have two priorities (normal and default, indicated with the keyword "default"), and the global attributes can be set with the command "attributes" (tests/tcsattset) - tcsim: IP_PCK and IP6_PCK now set the "protocol" attribute with "default" priority (tests/tcsattpro) - updated kernel version example in tcng/README from 2.4.18 to 2.4.19 (change log incorrectly stated this had been done already in 8u) - added warning when taking prefix of IPv4 or IPv6 constant instead of field (tests/constpfx, suggested by Jacob Teplitsky) - added warning switch "constpfx" to control above warning (tests/constpfx) - added new make target "immaculate" which also removes pre-built files - tcc/ports.tc is now removed by "immaculate", not "clean" - doc/Makefile can now re-generate EPS files (from FIG) - .depend is now always removed on "spotless", never on "clean" - various other minor "make clean" and "make spotless" corrections (most of them reported by Jacob Teplitsky) - added dummy targets "depend" and "dep" to doc/Makefile - documentation: added section describing parameter propagation rules - tcng/README now lists packages required for building and using tcng (suggested by "raptor") - setup.klib now reverts PSCHED_CLOCK_SOURCE to PSCHED_JIFFIES in case it was changed in the source tree (reported by "raptor") - runtests.sh got confused by END CONDITIONAL followed by BEGIN CONDITIONAL (tests/tstcond) - tcc let various types of "drop on" slip through, crashing it later (tests/dropon) - moved "drop on" test from tests/misfeatures to tests/dropon - tcsim_filter failed to select by device name (tests/tcng-8x) - documentation: -c was missing in "tcsim_filter tos=0xb8" example - tcsim_filter included packet ID in output, although documentation claims it doesn't, which makes more sense (tests/tcng-8x) - tcc failed to refuse element ID zero in "fw" filter (tests/tcng-8x) - updated tests/blocks, tests/cbqzero, tests/extndm, tests/location, tests/misfeatures, tests/newsynmsc, tests/semicolon, tests/tag, tests/tcng-5g, and tests/tcng-6w accordingly - tcsim/packet6.def:IP6_HDR did not initialize $ip6_plen - added pending issues related to protocol selection support to tcng/TODO -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng8w] make test errors (mandrake 2.4.19-9mdk)
raptor wrote: > This time errors are real :") That weird cpp strikes again. Which CPP version is this anyway ? Does putting #line 0 or #line 1 at the end of tcng/tcc/default.tc help or at least change the output in any way ? (According to the CPP 2.95.3, 3.1.1 and 3.2 docs, #line N should set the line number of the _next_ line to N, but CPP "2.96" (RH) and 3.1 set the line number of the current line, so the next line becomes N+1.) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc/htb still hangs system.
Tomasz Wrona wrote: > I tried to find reason but without success. Bellow I mention some > observed facts. Maybe someboty could advise or solve problem... In case you want to try systematic debugging of HTB, you may find tcsim useful. tcsim can be run under Electric Fence and under Valgrind (http://developer.kde.org/~sewardj/). It won't help you find race conditions and such, but spotting odd side-effects of parameter changes may be well within its capabilities. Of course, a decent set of regression tests should also be useful for future HTB development ... Concerning the Oops you got: you should run it through ksymoops (see Documentation/oops-tracing.txt in your kernel source tree). If you don't want to type in the whole Oops text, you can also get the location of individual symbols with gdb your/kernel/dir/vmlinux (gdb) info line *0xd093caa4 etc. The most useful data is in the EIP and the call trace. - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] PSCHED_CPU ?
raptor wrote: > ]- i386, tcng-8u, Mandrake 2.4.19mdk-9 Does the attached patch help ? With it, setup.klib simply reverts include/net/pkt_sched.h back to using PSCHED_JIFFIES. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// --- setup.klib.old Wed Sep 18 11:14:27 2002 +++ setup.klib Wed Sep 18 11:24:23 2002 @@ -100,7 +100,14 @@ u16 mask); \ trace_u32_offset(skb,n->handle,ptr-skb->nh.raw+n->sel.offoff,n->sel.offmask);\ & }/'>cls_u32.c - + +# +# De-Mandrakize net/pkt_sched.h +# + +sed 's/\(#define PSCHED_CLOCK_SOURCE[^ -~]*PSCHED_\)CPU/\1JIFFIES/' \ + <$KSRC/include/net/pkt_sched.h >include/net/pkt_sched.h + ln -s $KSRC kernel #
Re: [LARTC] [tcng] PSCHED_CPU ?
raptor wrote: > Will it be a problem if my kernel is compiled with PSCHED_CPU, but for > the success of the compilation of tcism I use PSCHED_JIFFES ? tcsim should just use PSCHED_JIFFIES, no matter what your kernel is configured to do. Quite obviously, this doesn't seem to be the case on your system. Is this a i386 platform ? And which kernel and which version of tcng are you using ? - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8w
... is on SourceForge, http://tcng.sourceforge.net/#src This one has the first steps towards getting non-IPv4 classification right: - I've added fields for skb meta-data (meta_protocol, etc.) - if USE_META_PROTOCOL is #defined (tcc -D... or tcsim -Xc,-D...), ip_hdr and ip6_hdr check the protocol number - if_u32 generates distinct classifier branches for each protocol - f_fw, f_tcindex, and f_u32 now default to ETH_P_ALL instead of ETH_P_IP The latter change affects how u32 classification works ! tests/protu32 illustrates how protocol-aware classification is used. What's missing: - C and tcc-ext-match need to support meta_protocol too - if_u32 does a few ugly things, and can also generate redundant filter stubs - remove USE_META_PROTOCOL :-) The next version will make meta data classification visible at the external interface, so if you're using this interface, this change will probably break your program. If you don't want to add support for meta fields to your program right now, you can simply work around the problem by redefinition ip_hdr and ip6_hdr to their old values (i.e. remove the if ... clause). The full change log is below. - Werner -- cut here --- Version 8w (13-SEP-2002) - added root of meta fields (__meta) and definitions for meta-fields in meta.tc (included via fields.tc) - added some layer > 2 protocol numbers to values.tc - tcsim's send command now has a "protocol" attribute (default: ETH_P_IP) - updated documentation according to above changes - ip_hdr and ip6_hdr now check meta_protocol if USE_META_PROTOCOL is #defined - added protocol selection support to if_u32.c (tests/protu32) - filters fw, tcindex, and u32, now default to ETH_P_ALL instad of ETH_P_IP - updated tests/cbqroot, tests/egress, tests/named, tests/selpath, tests/selpathcbq, tests/selpathdup, and tests/setpathgred accordingly - configure now detects and prints kernel extra version (e.g. pre7) -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8v
... is on SourceForge, http://tcng.sourceforge.net/#src This is yet another maintenance release. The main feature is that tcsim now supports HTB (well, it can configure it. I haven't tried yet to actually run any traffic through it.). I've also advanced all the surrounding infrastructure (regression tests, etc.) to make this useful. tcng needs a very recent 2.4.20 kernel pre-release and a patched iproute2 source tree for HTB. tcng/README describes how the latter is created. The full change log is below. - Werner -- cut here --- Version 8v (12-SEP-2002) - configure is now compatible with 2.4.20 (pre-release, tested with pre6), - tcsim/setup.klib: added struct notifier_block declaration for 2.4.20-pre6 compatibility - tcsim/setup.klib: disables psched_tick (added in 2.4.20) when terminating - added HTB and its various dependencies to the tcsim kernel build process - runtests.sh now only counts tests instead of running them if environment variable TCNG_TESTS_COUNT is set - runtests.sh: added conditional test execution (tests/tstcond) - runtests.sh: added command runtests for regression testing the regression test script - README: described how to build tcsim with HTB support (tests/htb) - tcsim now sets printk log level to KERN_WARNING (4) - tcsim: added option -k to set kernel logging threshold - updated documentation accordingly - added "help" target to top-level Makefile -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] dsmark_dequeue: unsupported protocol 2054
José Alberto Aguilar González wrote: > I am using dsmark in a DS Edge router and I got those "dsmark_dequeue: > unsupported protocol 2054" messages. > I know it is ARP traffic (2054=0x806) and I wonder how can I avoid that > kind traffic entering in the dsmark. Entering dsmark per se isn't a problem. dsmark will happily ignore your ARP traffic as long as you don't ask dsmark to actually (re)mark it. dsmark will notice that you're not trying to (re)mark the packets, if the dsmark class you're sending it to uses value 0 and mask 0xff. In case you really want to divert non-IP traffic, you need another qdisc around dsmark, and send only IPv4 and IPv6 traffic to the class to which dsmark is attached. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Implementation details of sch
Pedro Larroy wrote: > I'm trying to understand the sch implementation in the linux kernel. Is > there some documentation out there that may be helpful to me? ftp://icaftp.epfl.ch/pub/people/almesber/pub/tcio-current.ps.gz and, more recent, but not quite finished: ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8u
... is on SourceForge, http://tcng.sourceforge.net/#src This is a maintenance release. Highlights: - value << 0 was broken, oops - build process is compatible with the final release of 2.4.19 - make tcsim-rpms is now much better at finding sources. In particular, it will happily accept any source that configure recognizes as compatible, and no longer insist on exactly the recommended (i.e. latest) version And no, HTB support isn't in yet. But I've seen that 2.5.31 has it now. And UML (*). We're getting there ... (*) UML is the future of tcsim, see also http://www.almesberger.net/umlsim/ The full change log is below. - Werner -- cut here --- Version 8u (12-AUG-2002) - updated kernel version example in tcng/README from 2.4.18 to 2.4.19 - configure is now compatible with 2.4.19 (final release) - tcc refused to left-shift 32 bit values by 0 bits (tests/tcng-8u) - configure now checks for defective cpp (reported by "raptor") - added undocumented options --kversions and --iversions to configure - added script build/findsrc to locate source files - "make tcsim-rpms" now uses any supported version of kernel and iproute2, not only the suggested one - added more experimental code for FSM-based classification (not yet useful) - documentation: tcsim figure still called tcsim_filter and tcsim_plot "filter.pl" and "plot.pl" -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] correct config?
[EMAIL PROTECTED] wrote: > Below is my tests and I have some questions regarding them : > first it seems that classification doesnt happen at all ?! and it is > clear from the u32 filters 'cause they point to classes 1:1 and 1:2 which > doesnt exist at all ? They're dsmark classes and don't need explicit creation. They simply set skb->tc_index to 1 and 2, respectively. > Also I can't figure out which filter got used u32 or tc_index but > 'cause tcism_plot generates only enqueed packed and no dequee-packets. BTW, if you want to see what exactly is going on, you may want to use tcsim -v -v -v ... | tcsim_pretty > They have same priority but u32 is attached at root so they should be > used, right ? Yes. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] make test errors
[EMAIL PROTECTED] wrote: > --> out > :17: warning: unused variable x > --> ref > :1: warning: unused variable x Your cpp seems to count the lines of a file included with -include as lines of the main source file. Which version of cpp does this ? (cpp --version and/or cpp -v &1 | grep CPP ) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] [tcng] make test errors
[EMAIL PROTECTED] wrote: > Additive headers at external interface (C): FAILED > Standard error: > | input in flex scanner failed Does changing the line tcsim -v -Xc,-tif:c tests/lib/additive.tcsim | \ to tcsim -v -Xc,-tif:c tests/lib/additive.tcsim -I tests/lib | \ help ? > Meanwhile on two Mandrake's 8.2 when I try "make rpm" it don't work . Hmm, how does it fail ? > if I try "checkinstall make install" i also can't make .rpm... What is "checkinstall" ? > .OOOPS the kernel is 2.4.8 may be this is why this happen tcng should work with kernels as far back as 2.4.3. But the RPM build process looks for 2.4.18, yes. (It will happily take any other compatible kernel source tree if you change the name, though.) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8t
... is on SourceForge, http://tcng.sourceforge.net/#src The main features are that it fixes the CBQ busy loop problem and RPM builds (broken in 8s), and time specifications in tcsim are now more flexible. The full change log is below. The CBQ busy loop fix is admittedly ugly: there's only one way to explicitly make CBQ select a non-leaf class, and that's by using an invalid class number. Of course, filters detect this and complain ... with one exception: u32. That was close ;-) tcsim now supports the usual SI prefixes for seconds and jiffies. Also, "time" and "until" can use relative time now. Examples: time 1500mj /* at time 1500 millijiffies */ time +500us /* relative time */ every ... until +100s ... - Werner -- cut here --- Version 8t (16-JUL-2002) - tcc: changed some "error"s to "lerrors"s (by Jacob Teplitsky) - updated tests/tcng-4i accordingly - tcc selected CBQ class 0 when using negation, causing the kernel to busy loop (tests/cbqzero; reported by Bert Hubert) - updated tests/cbqroot accordingly - tcsim/cfg.[ly] claimed their names were tcsim.[ly] - tcsim allowed second and jiffie values to begin with opening square bracket (tests/tcng-8t) - tcsim now supports SI prefixes "M", "k", "m", and "u" for second and jiffie values (tests/tcssi) - tcsim now supports relative time for "time" and "until" (tests/tcsrelt) - updated documentation according to above two changes - copied acknowledgements from README to documentation preamble - began adding support for FSM-based classification to external interface (untested and undocumented) - changed "-C" to "nounspec" in all test titles of tests/defdsm - RPM build didn't build "shared" directory introduced in tcng 8s ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Tcng error
S Mohan wrote: > Does tcng require recompilation of kernel? No, but it needs the kernel and iproute2 source if you want to build tcsim too. If you don't want tcsim, just run ./configure -n If you want tcsim, look at the README for instructions. > I'm using RH7.3. Is there an rpm for RH? I don't know of any, but it would be good if someone who regularly builds RPMs for a reasonably large set of distributions/releases could include tcng (and, of course, let people know). tcng already supports building RPMs: make rpm and make tcsim-rpms - Werner -- _____ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tcng questions ?
[EMAIL PROTECTED] wrote:
> - Does tcng support HTB ? syntax ?
Not yet. Someone's working on implementing support for it, so I
hope to have it in the not too distant future.
> - what is the difference between "if" and "on" ?
"on" gives direct access to the filters of Linux traffic control,
while "if" provides a more abstract language.
I'm reading the docs but can get it right !
> "if" uses bool expressions and "on" is using only "u32", correct ?!
Half of it ;-) "on" supports all filters except u32. "if" uses u32
to do its work.
> what more?
Eventually, I plan to phase out "on". If you look at the documentation,
the elements in "The tcng language" are here to stay, while the ones in
"Under the hood" may change, and the ones in "Historical constructs"
should eventually disappear.
> - how can I tell tcng to use iptables for classifying and what is the
> syntax for it ?
You'll have to use the "fw" classifier. tcng doesn't touch iptables
directly, so you'd have to set up that classification separately.
For static classification, "if" is probably more convenient to use
than a mixture of iptables and tcng.
> if I want all packets that are not classified to be dropped what i have to do, is
>this correct :
>
> dev eth0 {
>class (1) if ;
>class (2) if ;
>class (3) drop if 1;
> }
It's either
dev eth0 {
name_of_qdisc { /* except if that qdisc is prio and your kernel isn't
very very recent */
class (1) if ...;
class (2) if ...;
drop if 1;
}
}
Or, better
dev eth0 {
egress {
class (<$c1>) if ...;
class (<$c2>) if ...;
drop if 1;
name_of_qdisc {
$c1 = class (1);
$c2 = class (1);
}
}
}
The second form gives you a better separation of classification
and queuing, and you also don't have to worry about drop not
working (in the case of "prio"). As a disadvantage, the second
form adds an indirection through "dsmark" and "tcindex".
- Werner
--
_
/ Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://icapeople.epfl.ch/almesber/_/
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] HZ to be 1000 - 2.5.25 may have this
Adam B. Fineberg wrote: > Can this be done in 2.4.18 by changing HZ in include/asm-i386/param.h to > 1000? Yes. > Would anything else need to be changed, like CLOCKS_PER_SEC (also > in param.h)? Hmm, CLOCKS_PER_SEC doesn't look right, particularly if you look at include/asm-ia64/ia32.h:IA32_CLOCKS_PER_SEC. It's only used for some obscure parameter-passing mechanism in ELF, so the damage should be quite limited. (I.e. I've never noticed anything going wrong when changing HZ, and I didn't realize the CLOCKS_PER_SEC dependency until now.) - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng version 8s
... is on SourceForge, http://tcng.sourceforge.net/#src Besides a bunch of minor corrections and improvements, this one fixes the rather embarrassing bug that IP address 255.255.255.255 was refused by tcc and tcsim. The full change log is below. - Werner -- cut here --- Version 8s (21-JUN-2002) - merged u128.[ch] from tcsim and tcc into shared/libtcngmisc.a - tcsim now sets the line style globally, such that it can be overridden with -cmd, e.g. -cmd "set data style linespoints" - tcsim_plot didn't check return value from system (reported by Bodo Bauer and Don Provan) - tests/tcng-8q exercises masking via offset and size (suggested by Jacob Teplitsky) - merged ipv4_host/ipv6_host from tcc and evaluate_ipv4 and evaluate_ipv6 from tcsim into shared/libtcngmisc.a - tcc and tcsim did not accept address 255.255.255.255 (tests/tcng-8q) - scripts/update-port-numbers.sh: increased ports file update interval from one week to 92 days, and switched to using temporary file for download - documented that "." does not work as an operator and therefore can't be used with parentheses (tests/misfeatures) -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tcng - what's next
[ Background: tcng is a system that allows traffic control configurations to be expressed in a much more natural way than with iproute2/tc, while retaining full compatibility. tcng can generate tc configuration commands, so no kernel changes are required. http://tcng.sourceforge.net/ ] I started tcng about one and a half years ago at EPF Lausanne, as part of a research project. Back then, the main goals were to provide a more friendly configuration language, and also to allow better abstraction between the configuration process and the underlying traffic control implementation. Then, work on tcng continued for one year on a contract with Bivio Networks, where I was graciously allowed to release most of my work to the public. The main result of this was the so-called "external interface" that can be used to drive hardware accelerators. Also, I got a lot of useful input from Jacob Teplitsky and others, and major usability and performance improvements were made during that time. Most importantly, while the original design assumed that all traffic control configurations would mirror the structure of traffic control in the Linux kernel, tcng now allows much better abstraction for classification. Now that my contract with Bivio Networks has ended, I'm continuing tcng as a hobbyist project. While I consider tcng to be sufficiently mature for serious use, there are still a few issues I plan to tackle, among them: - phase out "kernel-style" classification (the missing link for this is that "if" can't handle meta-data like skb->nfmark yet) - treat classifications as the construction of a finite state machine instead of the current ad hoc algebra. This is a hairy graph theoretical problem, but I expect major scalability improvements once I've solved this. - add loops to the classification mechanism (e.g. to walk through IPv4 options or IPv6 headers) - try to find a way to express queuing in an abstract and structured way, much like classification - and, of course, there are many minor misfeatures to address Since tcng is much broader than just Diffserv, I'm moving any discussion and announcements over to the LARTC mailing list (http://lartc.org/#mailinglist). I'm posting this message and the next release announcement to both lists. - Werner -- _________ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://icapeople.epfl.ch/almesber/_/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
