Re: [Lse-tech] Re: A common layer for Accounting packages

[Thomas Graf]

* 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/