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

From: Guillaume Thouvenin
Date: Tue Mar 01 2005 - 03:25:30 EST


On Mon, 2005-02-28 at 19:17 +0300, Evgeniy Polyakov wrote:
> On 28 Feb 2005 10:31:33 -0500
> jamal <hadi@xxxxxxxxxx> wrote:
> > 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.
> [...]
> 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.

I tested without user space listeners and the cost is negligible. I will
test with a user space listeners and see the results. I'm going to run
the test this week after improving the mechanism that switch on/off the
sending of the message.

Best regards,
Guillaume

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