[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1330606775.2465.56.camel@edumazet-laptop>
Date: Thu, 01 Mar 2012 04:59:35 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Rodrigo Moya <rodrigo.moya@...labora.co.uk>
Cc: David Laight <David.Laight@...LAB.COM>,
Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
David Miller <davem@...emloft.net>, javier@...labora.co.uk,
lennart@...ttering.net, kay.sievers@...y.org,
alban.crequy@...labora.co.uk, bart.cerneels@...labora.co.uk,
sjoerd.simons@...labora.co.uk, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: RE: [PATCH 0/10] af_unix: add multicast and filtering features to
AF_UNIX
Le jeudi 01 mars 2012 à 13:50 +0100, Rodrigo Moya a écrit :
> the main problem in D-Bus we are trying to solve is the context
> switches, since right now, there is a daemon, which listens on a UNIX
> socket, and all traffic in the bus goes through it, and then the daemon
> has to route the messages it gets on that socket to the corresponding
> place(s). So, every time someone sends a message to D-Bus, since all
> traffic goes through the daemon, dbus-daemon gets waked-up, which is one
> of the biggest bottlenecks we are trying to fix.
>
> That's why we are thinking about using multicast with socket filters, so
> that the daemon only gets traffic it cares about and thus is not waked
> up and context switches don't happen when not needed.
>
> Using message queues, AFAICS, we would have the same problem, as the
> daemon would create the message queue and would get all traffic, right?
>
This is why I mentioned extensions.
Anyway, if you think multicast sockets is the way to go, then you could
setup a virtual network just to be able to use AF_INET multicast.
Thats probably doable without kernel patching.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists