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

* jamal [ref] 2005-02-28 09:10

On Mon, 2005-02-28 at 08:53, Thomas Graf wrote:

quoted

* jamal [ref] 2005-02-28 08:40

quoted

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.