* jamal <1109599803.2188.1014.camel@xxxxxxxxxxxxxxxx> 2005-02-28 09:10
> On Mon, 2005-02-28 at 08:53, Thomas Graf wrote:
> > * jamal <1109598010.2188.994.camel@xxxxxxxxxxxxxxxx> 2005-02-28 08:40
> > >
> > > netlink broadcast or a wrapper around it.
> > > Why even bother doing the check with netlink_has_listeners()?
> > To implement the master enable/disable switch they want. The messages
> > don't get send out anyway but why bother doing all the work if nothing
> > will get send out in the end? It implements a well defined flag
> > controlled by open/close on fds (thus handles dying applications)
> > stating whether the whole code should be enabled or disabled. It is of
> > course not needed to avoid sending unnecessary messages.
> To justify writting the new code, I am assuming someone has actually sat
> down and in the minimal stuck their finger in the air
> and said "yes, there is definetely wind there".
I did, not for this problem though. The code this idea comes from sends
batched events of skb passing points to userspace. Not every call
invokes has_listeneres() but rather the kernel thread processing the
ring buffer sending the events to userspaces does. The result is
globally cached in a atomic_t making it possible to check for it at
zero-cost and really saving time and effort. I have no clue wether it
does make sense in this case I just pointed out how to do it properly
at my point of view.
> Which leadsto Marcello's question in other email:
> Theres some overhead.
> - Message needs to be built with skbs allocated (not the cn_xxx thing
> that seems to be invoked - I suspect that thing will build the skbs);
> - the netlink table needs to be locked
> -and searched and only then do you find theres nothing to send to.
> The point i was making is if you actually had to post this question,
> then you must be running into some problems of complexity ;->
> which implies to me that the delta overhead maybe worth it compared to
> introducing the complexity or any new code.
> I wasnt involved in the discussion - I just woke up and saw the posting
> and was bored. So the justification for the optimization has probably
> been explained and it may be worth doing the check (but probably such
> check should go into whatever that cn_xxx is).
I wasn't involved in the discussion either.
Using rtmsg_ifinfo as example, the check should probably go in straight
at the beginning _IFF_ rtmsg_ifinfo was subject to performance overhead
which obviously isn't the case but just served as an example.