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

From: jamal
Date: Mon Feb 28 2005 - 09:20:52 EST


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".

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).

cheers,
jamal

-
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/