Messages in this thread | | | Date | Mon, 28 Feb 2005 19:17:59 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [Lse-tech] Re: A common layer for Accounting packages |
| |
On 28 Feb 2005 10:31:33 -0500 jamal <hadi@cyberus.ca> wrote:
> On Mon, 2005-02-28 at 09:25, Thomas Graf wrote: > > * jamal <1109599803.2188.1014.camel@jzny.localdomain> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |