From: Casey Schaufler <casey@schaufler-ca•com>
To: Vincent Sanders <vincent.sanders@collabora•co.uk>
Cc: netdev@vger•kernel.org, linux-kernel@vger•kernel.org,
"David S. Miller" <davem@davemloft•net>
Subject: Re: AF_BUS socket address family
Date: Fri, 29 Jun 2012 11:45:10 -0700 [thread overview]
Message-ID: <4FEDF7B6.3020107@schaufler-ca.com> (raw)
In-Reply-To: <1340988354-26981-1-git-send-email-vincent.sanders@collabora.co.uk>
On 6/29/2012 9:45 AM, Vincent Sanders wrote:
> This series adds the bus address family (AF_BUS) it is against
> net-next as of yesterday.
>
> AF_BUS is a message oriented inter process communication system.
>
> The principle features are:
>
> - Reliable datagram based communication (all sockets are of type
> SOCK_SEQPACKET)
>
> - Multicast message delivery (one to many, unicast as a subset)
>
> - Strict ordering (messages are delivered to every client in the same order)
>
> - Ability to pass file descriptors
>
> - Ability to pass credentials
>
> The basic concept is to provide a virtual bus on which multiple
> processes can communicate and policy is imposed by a "bus master".
>
> Introduction
> ------------
>
> AF_BUS is based upon AF_UNIX but extended for multicast operation and
> removes stream operation, responding to extensive feedback on previous
> approaches we have made the implementation as isolated as
> possible. There are opportunities in the future to integrate the
> socket garbage collector with that of the unix socket implementation.
>
> The impetus for creating this IPC mechanism is to replace the
> underlying transport for D-Bus. The D-Bus system currently emulates this
> IPC mechanism using AF_UNIX sockets in userspace and has numerous
> undesirable behaviours. D-Bus is now widely deployed in many areas and
> has become a de-facto IPC standard. Using this IPC mechanism as a
> transport gives a significant (100% or more) improvement to throughput
> with comparable improvement to latency.
>
> This work was undertaken by Collabora for the GENIVI Alliance and we
> are committed to responding to feedback promptly and intend to continue
> to support this feature into the future.
>
> Operation
> ---------
>
> A bus is created by processes connecting on an AF_BUS socket. The
> "bus master" binds itself instead of connecting to the NULL address.
>
> The socket address is made up of a path component and a numeric
> component. The path component is either a pathname or an abstract
> socket similar to a unix socket. The numeric component is used to
> uniquely identify each connection to the bus. Thus the path identifies
> a specific bus and the numeric component the attachment to that bus.
>
> The numeric component of the address is divided into two fixed parts a
> prefix to identify multicast groups and a suffix which identifies the
> attachment. The kernel allocates a single address in prefix 0 to each
> socket upon connection.
>
> Connections are initially limited to communicating with address the
> bus master (address 0) . The bus master is responsible for making all
> policy decisions around manipulating other attachments including
> building multicast groups.
>
> It is expected that connecting clients use protocol specific messages
> to communicate with the bus master to negotiate differing
> configurations although a bus master might implement a fixed
> behaviour.
>
> AF_BUS itself is protocol agnostic and implements the configured
> policy between attachments which allows for a bus master to leave a
> bus and communication between clients to continue.
>
> Some test code has been written [1] which demonstrates the usage of
> AF_BUS.
>
> Use with BUS_PROTO_DBUS
> -----------------------
>
> The initial aim of AF_BUS is to provide a IPC mechanism suitable for
> use to provide the underlying transport for D-Bus.
>
> A socket created using BUS_PROTO_DBUS indicates that the messages
> passed will be in the D-Bus format. The userspace libraries have been
> updated to use this transport with an updated D-Bus daemon [2] as a bus
> master.
Why don't you go whole hog and put all of D-Bus into the kernel?
>
> The D-Bus protocol allows for multicast groups to be filtered depending
> on message contents. These filters are configured by the bus master
> but need to be enforced on message delivery.
>
> We have simply used the standard kernel netfilter mechanism to achieve
> this. This is used to filter delivery to clients that may be part of a
> multicast group where they are not receiving all messages according to
> policy. If a client wishes to further filter its input provision has
> been made to allow them to use BPF.
>
> The kernel based IPC has several benefits for D-Bus over the userspace
> emulation:
>
> - Context switching between userspace processes is reduced.
> - Message data copying is reduced.
> - System call overheads are reduced.
> - The userspace D-Bus daemon was subject to resource starvation,
> client contention and priority inversion.
> - Latency is reduced
> - Throughput is increased.
>
> The tools for testing these assertions are available [3] and
> consistently show a doubling in throughput and better than halving of
> latency.
Please cross-post Patches 04/15 and 05/15 to the linux-security-module list.
Please cross-post Patch 05/15 to the selinux list.
Where is the analogous patch for the Smack LSM?
>
> [1] http://cgit.collabora.com/git/user/javier/check-unix-multicast.git/log/?h=af-bus
> [2] http://cgit.collabora.com/git/user/rodrigo/dbus.git/
>
> [3] git://github.com/kanchev/dbus-ping.git
> https://github.com/kanchev/dbus-ping/blob/master/dbus-genivi-benchmarking.sh
> --
> 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/
>
next prev parent reply other threads:[~2012-06-29 18:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-29 16:45 AF_BUS socket address family Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 01/15] net: bus: Add " Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 02/15] net: bus: Add documentation for AF_BUS Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 03/15] net: bus: Add AF_BUS socket and address definitions Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 04/15] security: Add Linux Security Modules hook for AF_BUS sockets Vincent Sanders
2012-07-09 3:32 ` James Morris
2012-07-09 18:02 ` Paul Moore
2012-06-29 16:45 ` [PATCH net-next 05/15] security: selinux: Add AF_BUS socket SELinux hooks Vincent Sanders
2012-07-09 18:38 ` Paul Moore
2012-06-29 16:45 ` [PATCH net-next 06/15] netfilter: Add NFPROTO_BUS hook constant for AF_BUS socket family Vincent Sanders
2012-07-01 2:15 ` Jan Engelhardt
2012-06-29 16:45 ` [PATCH net-next 07/15] scm: allow AF_BUS sockets to send ancillary data Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 08/15] net: bus: Add implementation of Bus domain sockets Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 09/15] net: bus: Add garbage collector for AF_BUS sockets Vincent Sanders
2012-07-02 17:44 ` Ben Hutchings
2012-07-03 12:11 ` Alban Crequy
2012-06-29 16:45 ` [PATCH net-next 10/15] net: bus: Add the AF_BUS socket address family to KBuild Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 11/15] netlink: connector: implement cn_netlink_reply Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 12/15] netlink: connector: Add idx and val identifiers for netfilter D-Bus Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 13/15] netfilter: nfdbus: Add D-bus message parsing Vincent Sanders
2012-06-29 17:11 ` Pablo Neira Ayuso
2012-07-02 15:43 ` Javier Martinez Canillas
2012-07-04 17:30 ` Pablo Neira Ayuso
2012-07-05 17:54 ` Javier Martinez Canillas
2012-06-29 16:45 ` [PATCH net-next 14/15] netfilter: nfdbus: Add D-bus match rule implementation Vincent Sanders
2012-06-29 16:45 ` [PATCH net-next 15/15] netfilter: add netfilter D-Bus module Vincent Sanders
2012-06-29 18:16 ` AF_BUS socket address family Chris Friesen
2012-06-29 19:33 ` Ben Hutchings
2012-06-29 18:45 ` Casey Schaufler [this message]
2012-06-29 23:22 ` Vincent Sanders
2012-06-29 22:36 ` David Miller
2012-06-29 23:12 ` Vincent Sanders
2012-06-29 23:18 ` David Miller
2012-06-29 23:42 ` Vincent Sanders
2012-06-29 23:50 ` David Miller
2012-06-30 0:09 ` Vincent Sanders
2012-06-30 13:12 ` Alan Cox
2012-07-01 0:33 ` David Miller
2012-07-01 14:16 ` Alan Cox
2012-07-01 21:45 ` David Miller
2012-06-30 0:13 ` Benjamin LaHaise
2012-06-30 12:52 ` Alan Cox
2012-07-02 14:51 ` Vincent Sanders
2012-07-02 4:49 ` Chris Friesen
2012-07-05 21:06 ` Jan Engelhardt
2012-07-06 18:27 ` Chris Friesen
2012-06-30 20:41 ` Hans-Peter Jansen
2012-07-02 16:46 ` Alban Crequy
2012-07-05 7:59 ` Linus Walleij
2012-07-05 16:01 ` Daniel Walker
-- strict thread matches above, loose matches on Subject: below --
2012-07-02 15:18 Javier Martinez Canillas
2012-07-03 16:52 ` Chris Friesen
2012-07-03 17:18 ` Chris Friesen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FEDF7B6.3020107@schaufler-ca.com \
--to=casey@schaufler-ca$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=vincent.sanders@collabora$(echo .)co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox