On 08.12.2010 12:54, Michal Sojka wrote: > On Tue, 07 Dec 2010, Oliver Hartkopp wrote:
>> The question is if we could allow >> >> - the (currently enabled) routing to the originating interface (can0 -> can0) >> - the routing over several hops (can0 -> vcan0 -> vcan1 -> can0) >> >> without any restrictions. >> (..) > I'm not completely familiar with > softirq logic so there might by some mechanisms to avoid stack overflow > and to defer the work to later time, but in any case it will load the > CPU by 100%. Yes. Indeed in netif_rx_ni() the soft-irq is raised after the skb is enqueued. And if we do the routing several times we might probably run into a stack overflow - especially with vcan's. When having a 'good' CAN interface which supports the echo of CAN frames on driver level this won't be a problem. > Maybe we could use skb->dropcount (or some other field) to count the > number of hops and drop the packet after some (perhaps configurable) > value. I checked the existing fields of struct skbuff. E.g. skb->dropcount is a union with skb->mark, which we probably need to use in the future. In the SocketCAN SVN Rev. 1225 i changed the skb->sk handling to use the (in CAN skbs) unused mac_header offset. See 'svn log -r1225' for details. > So the question is what multi-hop routing brings new when compared to > single hop routing. Is there anything? Hm - i'm still searching for the killer application for multi hop routings 8-) Thanks for you opinion, Oliver _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
