On 28 Feb 2005 10:31:33 -0500
jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-28 at 09:25, Thomas Graf wrote:
> > * jamal <[EMAIL PROTECTED]> 2005-02-28 09:10
> [..]
> > > 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
>
> I would bet the benefit you are seeing has to do with batching rather
> than such an optimization flag. Different ballgame.
> I relooked at their code snippet, they dont even have skbs built nor
> even figured out what sock or PID. That work still needs to be done it
> seems in cn_netlink_send(). So probably all they need to do is move the
> check in cn_netlink_send() instead. This is assuming they are not
> scratching their heads with some realted complexities.
>
> I am gonna disapear for a while; hopefully the original posters have
> gathered some ideas from what we discussed.
As connector author, I still doubt it worth copying several lines
from netlink_broadcast() before skb allocation in cn_netlink_send().
Of course it is easy and can be done, but I do not see any profit here.
Atomic allocation is fast, if it succeds, but there are no groups/socket to
send,
skb will be freed, if allocation fails, then group check is useless.
I would prefer Guillaume Thouvenin as fork connector author to test
his current implementation and show that connector's cost is negligible
both with and without userspace listeners.
As far as I remember it is first entry in fork connector's TODO list.
> cheers,
> jamal
>
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
