Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756423AbbDOWJB (ORCPT ); Wed, 15 Apr 2015 18:09:01 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:43852 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753484AbbDOWIx (ORCPT ); Wed, 15 Apr 2015 18:08:53 -0400 Date: Wed, 15 Apr 2015 23:08:16 +0100 From: One Thousand Gnomes To: Havoc Pennington Cc: Rik van Riel , Greg Kroah-Hartman , Jiri Kosina , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415230816.657d2130@lxorguk.ukuu.org.uk> In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3011 Lines: 64 > When trying to split apart problems, for dbus it's important to keep > ordering guarantees. Yes I assumed that - minus disconnection/reconnect and running out of queue space. Some users also want priority queueing (with or without the guarantee for the same priority). Many of the other systems that can use a fast multicast messaging system have priority queues - which is one reason the existing POSIX messaging has priority. > That is, with dbus if I send a broadcast message, then send a unicast > request to another client, then drop the connection causing the bus to > broadcast that I've dropped; then the other client will see those > things in that order - the broadcast, then the request, and then that > I've dropped the connection. That's a simple matter of refcounting the buffers 8). I'm not really concerned about the low level queue side of things. The proposed implementation looks horribly convoluted for what the sk_buff layer can already do standing on one leg. We know how to implement that part cleanly, and its probably not hard to nail onto AF_UNIX or to expand posix message queues to provide that service (and maybe then even convince POSIX about it) If it was just "here's a general purpose multicast message service" in a small clean chunk of code I'd be cheering it into the tree. Even if you need complicated filter rules because we can use EBPF to allow the client library to do really sophisticated filtering and avoid wakeups for noise. It's the complexity, the attachment to a lot of state in kernel and the fact it doesn't appear to solve the general purpose problems that bothers me. > By pushing everything through one queue, dbus is trying to reduce the > number of codepaths in applications. Apps have a lot of new problems > to solve if messages get their order scrambled. And I assume any user space solution for that purpose would end up re-ordering messages if they could get shuffled so its > (dbus does NOT guarantee order across multiple clients, of course - > there's no guarantee that all clients get the broadcast, before anyone > gets the next message - each client has its own buffer on both read > and write. The ordering is only with respect to each client's message > stream.) > > Ordering is vital for tracking state, because if you're sending out > events to describe changes in state, the order of those changes is > important. Most of the time IMHO you don't want to listen to changes in state, you want to notice that the state wasn't the value it was before and adapt. > Of course there are more complex ways to handle this over in > distributed-systems-world. And publish/subscribe models - which for certain uses scale better, are easier to make reliable and avoid a lot of the mess. Alan -- 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/