Hi,

Is IMQ still maintained? I am using IMQ to shape ingress traffic.
But the application is a streaming server (VLC). However, the kernel
reboots immediately as quick as can hardly been seen what is
wrong with it.

Any help with this kinda problem?

Thanks,
Shawn
 				
--------------
Y. D.
2009-04-22

--

[ message continues ]

IMQ isn't a part of kernel/netfilter, so you should try at its own
site/mailing list.

Jarek P.
--

[ message continues ]

I'd rather suggest to get rid of it and use ifb, AFAIK there hasn't
been a single version in all those years that didn't cause this kind
of problems.
--

[ message continues ]

I'd rather point out that ifb does not seem to be able to do all of what 
IMQ can, up to the point where it is believed in the public that ifb is 
practically useless.
--

[ message continues ]

I'm aware of those claims, but not of the details. If this is true,
people should raise those issues and help resolve them. I wouldn't
hold my breath waiting for IMQ to get fixed.

--

[ message continues ]

I would love to see a way to change where IFB hooks [if "hook" is the
right term ], till now i dont think i am able to hook it after nat in
prerouting and before nat in postrouting. Is there a way to do this ?
What i basically do with IMQ is:


                         eth0 [192.168.0.0/24]
ppp0   <---->       eth1 [192.168.1.0/24]
                         eth2 [192.168.2.0/24]

Using imq i can shape upload on ppp0 [postrouting] while still having
the internal private ips from the hosts, and i can shape download in
ppp0 [prerouting] after get the correct nat'ed addresses.




-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".
--

[ message continues ]

Currently not, the conntrack association is done at a later point.
We could add a classifier or TC action that performs the lookup
during ingress classification.

Alternatively classifiers using conntrack information (like cls_flow)
could perform the lookup directly, but that would probably get a bit
ugly since some validation needs to be performed previously and it
would add a module dependency on conntrack.

--

[ message continues ]

On Thu, Apr 23, 2009 at 01:22:19PM +0200, Patrick McHardy wrote:

BTW, some time ago I started to wonder how safe are those various
ingress activities wrt. invalid packets, dropped later in ip_rcv().

Jarek P.
--

[ message continues ]

Leaving aside the ipt action, I'm not aware of any problems caused
by ingress classification. Could you be more specific?
--

[ message continues ]

There is nothing specific yet. I hope these other classifiers and
actions aren't mislead too much to go astray.

Jarek P.
--

[ message continues ]

Generally, there shouldn't be any problems specific to ingress since
the classifiers have to expect all kinds of invalid packets on egress
as well.
--

[ message continues ]

Using this actions would make  sfq hashing by dest ip or source ip
work just like it works in imq ?


-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".
--

[ message continues ]

Not with the SFQ default hash since it classifies based on the
addresses in the IP header. But you could use the flow classifier,
which can use the addresses from the conntrack entry. This would
behave similar to IMQ+SFQ.

--

[ message continues ]

Ok , i was tying to keepthe discussion to the mainline kernel :)
By sfq i mean esfq [though i read somewhere sfq will implement a way
to hash by src / dest ip] , or wrr :)
Actually i was never able to find out why wrr is not in mainline
kernel. In my opinion it is the best round robin qdisc i have ever



-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".
--

[ message continues ]

There is DRR since a couple of versions. Combined with the
flow classifier, it should provide the same functionality
as ESFQ.
--

[ message continues ]

I think it is even better, as soon as you understand it, it is very intuitive 
to understand and transparent, how it works.
--

[ message continues ]

I am just curious , is there a qdisc in mainline that behaves similar
to wrr [weight round robin] ?
http://www.zz9.dk/wrr


-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".
--

[ message continues ]

DRR. But it can't do those strange load-balancing hacks.
--

[ message continues ]

what would it be those strange ugly hacks ? :)
Any good place where i can find DRR documentation/examples ?

-- 
[]'s
Salatiel

"O maior prazer do inteligente é bancar o  idiota
   diante de um  idiota que banca o inteligente".
--

[ message continues ]

No, but I can give you an example:

tc qdisc add dev <dev> parent <parent> handle <handle> drr

tc class add dev <dev> parent <handle> classid <classid> drr

repeat class add as often as you need. The default quantum per
class is the MTU, including link layer headers. You can manually
change that by specifying the "quantum" parameter for classes.

As for the flow classifier:

tc filter add dev <dev> protocol all pref 1 parent <handle> \
	flow hash keys key1,key2,... divisor <number of classes>

The DRR classids need to be consequitive for this to work.
--

[ message continues ]