Hello! > I get your point and I see the value. Unfortunately, probably due to > lack of documentation, this feature isn't used by any applications I > know of.
Well, tc was supposed to use it, but this did not happen and it remained deficient. > We even put in the hacks to make identification of own caused > notifications easier by storing the netlink pid of the originator in > the notification message. Actually, it was supposed to be done everywhere, but originator info did not propagate deep enough in many cases, especially in IPv6. So, this is not a hack, it is a good work. :-) BTW I have just remembered why it was especially important, this should be documented as well. Each socket, which subscribes to multicasts becomes sensitive to rcvbuf overflows. F.e. when you do control operations on a socket, which is subscribed to multicasts, the response can be lost in stream of events and -ENOBUFS generated instead. If it is a daemon, it can resync the state, but if it is a simple utility, it cannot recover. Probably, unicasts sent due to NLM_F_ECHO should somehow override rcvbuf limits. This reminded me about a capital problem, found by openvz people. Frankly speaking, I still have no idea how to repair this, probably you will find a solution. Look: while a dump, skb allocation can fail (because of many reasons, the most obvious is that rcvbuf space was eaten by multicasts). But error is not reported! Oops. The worst thing is that even if an error is reported, iproute would ignore it. Alexey - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
