Messages in this thread | | | Date | Fri, 18 Feb 2000 00:02:29 +0100 | From | Henner Eisen <> | Subject | Re: 2.3.4x softnet watchdog and (isdn) demand dialing |
| |
Hi Alexy,
>>>>> "kuznet" == kuznet <kuznet@ms2.inr.ac.ru> writes:
kuznet> Listen, let's discuss this in more details. I thought kuznet> about this yesterday and found that I did not understand kuznet> the problem probably.
kuznet> Could you describe control flow, which you expect? Events kuznet> are: device open, dial-on-demand, packet sent etc.
Currently, it is like this:
ifconfig up: -> device is open. device remains open, no matter whether the isdn connection is up or down.
isdn connection is up: -> Nothing special, tbusy (or the equivalent softnet stuff) is set in the usual manner. (tbusy set in isdn_net_hard_start_xmit() if internal queues are full, tbusy cleared when hardware irq signals that queue is empty enough again.)
If isdn connenction is down and no pending traffic for the device: Tbusy is not set. Now, if network layer sends down a packet to the isdn netdevice, the interface triggers demand dialing. isdn_net_start_xmit() returns 1 and sets tbusy. Thus, network layer ceases sending down further packets. If network layer queues further packetes for the isdn netdevice, those packets will stay in the packet scheduler/device queues.
When in demand dialing stage (with tbusy set): if isdn connection is established, tbusy is cleared. The network layer will now restart sending the packets in the device queues immediately. If establishing the connection fails, all internal queues are purged, the qdisc is reset, and tbusy will also be cleared again such that the devide is in the idle state again.
kuznet> The most suspicious moment is period when tbusy is set. kuznet> F.e. device should not hold it for very long kuznet> time. Actually, if dialing is long, it is better to clear
Usually, it is not long. Might be less than a second for rawip encapsulation, but with ppp it might take longer due to pppd negociation delays. With interfaces configured for and waiting for a callback from the peer, delay will also increase.
kuznet> queue instead of tail drop, otherwise some datagram kuznet> services, which are not supposed to block in write(), kuznet> could block for too long time. Probably, we should make kuznet> this engine more clever than it is.
Something like: If conenction is not up after a few seconds, clear all queues and reset qdisc, but remain in dialing stage?
kuznet> Another moment: do you really understand that now packets kuznet> never achieve driver, if tbusy is set? Another difference,
Yes.
kuznet> which can be confusing and, seems, not clever, is that kuznet> watchdog is called even if no packets are queued. See? kuznet> Please, blame 8)
That's what I was wondering about, but did not try to figure out yet.
kuznet> Alexey
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |