Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-23 Thread Dzianis Kahanovich
Too many pixels to smoke. Sorry. May be so? ;)) (if undefined classid not overwrited by random value tc_classify) Even "tc" say to classid=0 - "" --- 1/net/sched/sch_ingress.c 2008-01-12 17:27:05.0 +0200 +++ 2/net/sched/sch_ingress.c 2008-01-22 22:09:32.0 +0200 @@ -136,6

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-22 Thread Dzianis Kahanovich
Too many pixels to smoke. Sorry. May be so? ;)) (if undefined classid not overwrited by random value tc_classify) Even "tc" say to classid=0 - "" --- 1/net/sched/sch_ingress.c 2008-01-12 17:27:05.0 +0200 +++ 2/net/sched/sch_ingress.c 2008-01-22 22:09:32.0 +0200 @@ -136,6

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-16 Thread jamal
On Mon, 2008-14-01 at 20:20 -0200, Dzianis Kahanovich wrote: > jamal wrote: [..] > > Did that make sense? > > After current "#endif" - may be. I am afraid that would be counter to expected behavior. Default is meant to apply when no value has been defined. Mark of 0 for example doesnt mean "def

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-14 Thread Dzianis Kahanovich
jamal wrote: May be I am mix in mind other code (multi-class loop/walking) and this code. I am deprogramming... ;) Sorry, I just change focus from existing "tc_index=..." to common behaviour ;) [...] Please refer to what i said above; if what i said still doesnt make sense i can create (t

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-14 Thread jamal
On Mon, 2008-14-01 at 13:40 -0200, Dzianis Kahanovich wrote: > jamal wrote: > Yes, I only do it by inertia after "#define tc_index mark". And i am afraid this bothers me greatly. You already have ways to achieve what you need by setting proper policy, the difference in configuration is an extra o

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-14 Thread Dzianis Kahanovich
jamal wrote: I in doubts only about "action continue". To "and/or" behaviour one of best usage are (example): I dont think you should be touching the action part at all primarily because actions can set the mark after classification. Yes, I only do it by inertia after "#define tc_index mark

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-13 Thread jamal
Hi, Please CC me in your responses (the way i do when i respond to you), that way my filters prioritize your email. On Sat, 2008-12-01 at 15:56 -0200, Dzianis Kahanovich wrote: > I in doubts only about "action continue". > To "and/or" behaviour one of best usage are (example): I dont think you

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-12 Thread Dzianis Kahanovich
I in doubts only about "action continue". To "and/or" behaviour one of best usage are (example): # set bit 2 of mark to 0 (mark&0xfd|0) and continue tc filter add ... prio 1 ... flowid fd:0 action continue # continue tc filter add ... prio 2 ... - in current ingress_enqueue() code IMHO "case TC_

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-11 Thread jamal
On Fri, 2008-11-01 at 18:42 -0200, Dzianis Kahanovich wrote: > About script example: > While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch > applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to > change mark. All in ingress only. For example: > tc fi

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-11 Thread Dzianis Kahanovich
jamal wrote: Yes, I do so. But there are simple: --- if [[ $[TC_INDEX2MARK] == 0 ]] ; then ==1 c=${c//action ipt -j MARK --set-mark /flowid :} c=${c//action ipt -j MARK --set-mark 0x/flowid :} fi $c --- I didnt quiet understand what you have above. Does your script above read the flow

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-11 Thread jamal
On Fri, 2008-11-01 at 15:24 -0200, Dzianis Kahanovich wrote: > jamal wrote: > > tc qdisc add dev XXX ingress > > tc filter add dev XXX parent : protocol ip prio 5 \ > > u32 blah bleh \ > > flowid 1:12 action ipt -j mark --set-mark 13 > > Yes, I do so. But there are simple: > --- > if [[ $[T

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-11 Thread Dzianis Kahanovich
jamal wrote: To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", etc). --- linux-2.6.23-gentoo-r2/net/sched/Kconfig +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig @@ -222,6 +222,16 @@ [..] skb->tc_index = TC_H_MIN(res.classid); +#ifdef CONFIG

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-11 Thread Dzianis Kahanovich
Patrick McHardy wrote: --- linux-2.6.23-gentoo-r2/net/sched/sch_ingress.c +++ linux-2.6.23-gentoo-r2.fixed/net/sched/sch_ingress.c @@ -161,2 +161,5 @@ skb->tc_index = TC_H_MIN(res.classid); +#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK +skb->mark = (skb->mark&(res.classid>>16)

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-10 Thread jamal
On Thu, 2008-10-01 at 17:05 -0200, Dzianis Kahanovich wrote: > To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", > etc). > > --- linux-2.6.23-gentoo-r2/net/sched/Kconfig > +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig > @@ -222,6 +222,16 @@ [..] >

Re: [PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-10 Thread Patrick McHardy
Dzianis Kahanovich wrote: --- linux-2.6.23-gentoo-r2/net/sched/sch_ingress.c +++ linux-2.6.23-gentoo-r2.fixed/net/sched/sch_ingress.c @@ -161,2 +161,5 @@ skb->tc_index = TC_H_MIN(res.classid); +#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK +skb->mark = (skb->mark&(res.classid>>1

[PATCH 2.6.23+] ingress classify to [nf]mark

2008-01-10 Thread Dzianis Kahanovich
To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", etc). --- linux-2.6.23-gentoo-r2/net/sched/Kconfig +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig @@ -222,6 +222,16 @@ To compile this code as a module, choose M here: the module will be called sch_