Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754002AbbDXKvF (ORCPT ); Fri, 24 Apr 2015 06:51:05 -0400 Received: from mail.skyhub.de ([78.46.96.112]:44952 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753718AbbDXKvA (ORCPT ); Fri, 24 Apr 2015 06:51:00 -0400 Date: Fri, 24 Apr 2015 12:50:48 +0200 From: Borislav Petkov To: Daniel Mack Cc: Steven Noonan , David Herrmann , Greg Kroah-Hartman , "Eric W. Biederman" , Linus Torvalds , Andrew Morton , Arnd Bergmann , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , Andy Lutomirski , linux-kernel , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150424105047.GA24894@pd.tnic> References: <20150413190350.GA9485@kroah.com> <8738434yjk.fsf@x220.int.ebiederm.org> <20150422085827.GA6962@pd.tnic> <20150423191433.GB13607@kroah.com> <20150423205640.GR28327@pd.tnic> <20150423214111.GT28327@pd.tnic> <20150424090402.GA24014@pd.tnic> <553A1AE6.9060902@zonque.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <553A1AE6.9060902@zonque.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3345 Lines: 80 Hi, On Fri, Apr 24, 2015 at 12:28:54PM +0200, Daniel Mack wrote: > Sure, for broadcasts, we have to walk the list of peers connected to the > bus and see which one is interested in a particular message. We do that And this "... we have to walk the list ..." right there raises the alarm. Can this walking of elements where you know they wouldn't match be avoided? > by looking at the match rules of each of them, which are based on > well-known names, IDs, notification types or bloom filters. The policy > logic limits this further, as receivers of a broadcast must have TALK > access to the sender. So it sounds to me like there are characteristics which can already prepare lists of recipients interested in some sort of message. So would it be possible for recipients to "register" for such messages and the sending side would simply iterate a list of solely interested recipients? This will definitely save you the iteration over all n connections and would make the metadata collection probably not needed (or at least a subset of it) because recipients will have to establish eligibility for receiving a certain message at register time and once they're on the list, you implicitly know why they're there. I don't know whether that fits all use cases but it definitely does only the *necessary* work for message transfer and not more. > If these rules let a message pass, all the metadata that the receiving > peer asked for (by setting a flag at connect time) is collected, unless > it has been collected already for some other peer for the same message. > In other words, in worst case, we collect all the metadata items exactly > once per message. Right. > If none of the connections with permissive match/policy rules for a > message is interested in any metadata items, nothing will be collected > at all. But we still iterate through there and look at the arg @what and ->collected. And this is useless work which can be avoided IMHO. > If the receiving side doesn't need it, it shouldn't opt-in for that > piece of information. > > The metadata logic is really only there so receiving peers are directly > supplied with information that they would otherwise look up themselves > from /proc or something. Also, we collect metadata at send time and for > every message intentionally, so that it reflects the state of the sender > at the time of sending. This way, the information is not subject to > races of asynchronous lookups. Ok. > > Now, one might argue that you have to do O(n) work when broadcasting > > to n recipients anyway and you can't get that cheaper but maybe the > > design is not optimal. Maybe it could be made to not broadcast at all, > > or broadcast to a subset of recipients, only those which are actually > > interested in the broadcast. > > That's exactly what happens :) There are some more details on this in > kdbus.match(7). But this is not for KDBUS_DST_ID_BROADCAST types, right? Because there you have to iterate over *all* recipients in the connection hash. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/