Re: Re: A common layer for Accounting packages

I'm net ignorant, so just hit me with a cluebat if thats appropriate.

On Mon, Feb 28, 2005 at 07:10:58AM -0500, jamal wrote:

Havent seen the beginnings of this thread. But whatever you are trying
to do seems to suggest some complexity that you are trying to
workaround. What was wrong with just going ahead and just always
invoking your netlink_send()? 

What overhead does the netlink_send() impose if there are no listeners? 

Sure, it wont go anywhere, but the message will have to be assembled and sent 
anyway. Correct? 

The way things are now, its necessary to make the decision to invoke or not 
netlink_send() due to the supposed overhead. 

Thats what Guillaume is doing, and thats what will have to be done whenever
one wants to send information through netlink from performance critical paths.

Can't the assembly/etc overhead associated with netlink_send() be avoided
earlier, approaching zero-cost ? 

Being able to get rid of the decision to invoke or not the sendmsg would be nice.

TIA

If there are nobody in user space (or
kernel) listening, it wont go anywhere.

cheers,
jamal

On Mon, 2005-02-28 at 02:39, Andrew Morton wrote:

quoted

Guillaume Thouvenin [off-list ref] wrote:

quoted

   Ok the protocol is maybe too "basic" but with this mechanism the user
 space application that uses the fork connector can start and stop the
 send of messages. This implementation needs somme improvements because
 currently, if two application are using the fork connector one can
 enable it and the other don't know if it is enable or not, but the idea
 is here I think.

Yes.  But this problem can be solved in userspace, with a little library
function and a bit of locking.

IOW: use the library to enable/disable the fork connector rather than
directly doing syscalls.

It has the problem that if a client of that library crashes, the counter
gets out of whack, but really, it's not all _that_ important, and to handle
this properly in-kernel each client would need an open fd against some
object so we can do the close-on-exit thing properly.  You'd need to create
a separate netlink socket for the purpose.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click