>this is qute intersting, and it happens on every computer not only on bussy
>ones
>but in reality I dont see any need for that, because tcp itself should take
>care of this issue.
>
Right but you lost TCP interactivity and overloaded WiFi interface is painfull itself !!!
>anyway this may solve some problems with crashes, because I suspect imq is
>unstable because of this problem.
>
Stability if any current implementations is issue by design. Simply something betwen netfilter and TCP/IP stack. I tried found it but my suceess was only more crashes.
>I looked at yor code and do not understand what it does, do you implemented
>that EOS for imq interface ifself?
>this is not logical, since imq is not interface, it is placeholder to attach
>shapers.
>Or you made that your imq takes packets from kernel ant transmits them by
>itself without returning to netfilter
>with dev_queue_xmit(skb)
>this way you are very limited in what you are able to do because you can
>hook only on the last hook.
>
There is skb->imq_flags whis getting marked by netfilter to IMQ_F_ENQUEUE (part of flag is target IMQ network interface)
At "end of life in kernel" every packet coming into dev_queue_xmit. There also come our marked skb. When you have look at begin of the modified dev_queue_xmit
there is imq_flags decoder. When decoder hit our marked SKB its enqueued in to IMQ queue. Then we run qdisc dequeue (qdisc_run).
qdisc_run function is a loop tat run qdisc restart until is queue empty, need to be schedulet (netif_schedule) or until is not set netif_queue_stopped atomic bit (bingo the trick is here). After dequeue in qdisc restart our skb passing hard_start_xmit function in IMQ driver. After some checkings is there stopped queue of the imq device (netif_queue_stopped), changet skb->imq_flags to IMQ_F_ENQUEUED and passed back to dev_queue_xmit. Now it will hit our real device, and at end of the qdisc_restart (after hard_start_xmit) is function that decode the skb->imq_flags and if is necesary wake_up the queue of our IMQ device (so we have perfect synchronization of the EOS). There is some protection to lock up the queue in imq_dev_xmit (imq.c). Also there are counted throtled skb by collision counter. I also use device watchdog to solve problem if skb stuck somewhere in physical device queue and netif_wake_queue is not called in right time( its only protection "for sure" because this should happen and if this happen without protection behind this, whole imq should lockup and kill the trafics forewer)
>seems you may be unable shape ingress then. what basicaly voids all imq
>purpose.
>
Iam not sure. Every packet comin in in to router must come out !!! So we need only shape out trafics. Incoming trafics we cannot shape, only police. We cannot change speed and rate of incoming packets !!! have look at example includet in my IMQ. There i use the corret way to shape incoming and outgoung traffic. BTW: I have writen a TODO ....
>unfortunately you made your driver even more invasive than old one,
>it need to patch almost all kernel network system.
>
Yes its also angle of view :) I was need to solve problem and i solve it. Everithing there is clear. IMHO Cannot be solved by more clear solution. ;)
Zkontrolovane antivirusom ClamAv Scanned by ClamAv - http://www.clamav.net _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
