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

[Marcelo Tosatti]

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:
> > Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxx> wrote:
> > >
> > >    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.
-
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/