On Thu, Jan 20, 2005 at 08:56:11AM -0800, Stephen Hemminger wrote: > You might want to enforce that LLTX devices like tunnels need to > have no transmit queue (tx_queue_len == 0)?
I didn't look at the original LLTX patch, so I'm speaking out of ignorance, but since we're on this subject anyway: I noticed that the ip_gre tunneling driver contains this comment: <quote> 1. The most important issue is detecting local dead loops. They would cause complete host lockup in transmit, which would be "resolved" by stack overflow or, if queueing is enabled, with infinite looping in net_bh. We cannot track such dead loops during route installation, it is infeasible task. The most general solutions would be to keep skb->encapsulation counter (sort of local ttl), and silently drop packet when it expires. It is the best solution, but it supposes maintaing new variable in ALL skb, even if no tunneling is used. Current solution: t->recursion lock breaks dead loops. It looks like dev->tbusy flag, but I preferred new variable, because the semantics is different. One day, when hard_start_xmit will be multithreaded we will have to use skb->encapsulation. </quote> If multiple CPUs can call into the tunneling drivers without taking any locks, we'd need some extra locking in there, or just do what Alexey describes and keep track of recursion in the skb. The recursion detection in dev_queue_xmit would perhaps also want to use such a per-skb mechanism instead of using dev->xmit_lock_owner. (You really _do_ want the protection that this mechanism offers.) --L _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
