netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/11] netlink: memory mapped I/O
@ 2012-08-20  6:18 Patrick McHardy
  2012-08-20  6:18 ` [PATCH 01/11] netlink: add symbolic value for congested state Patrick McHardy
                   ` (11 more replies)
  0 siblings, 12 replies; 20+ messages in thread
From: Patrick McHardy @ 2012-08-20  6:18 UTC (permalink / raw)
  To: Florian.Westphal; +Cc: netdev, netfilter-devel

The following patches contain an implementation of memory mapped I/O for
netlink, rebased onto the current net-next tree. The implementation is
modelled after AF_PACKET memory mapped I/O with a few differences:

- In order to perform memory mapped I/O to userspace, the kernel allocates
  skbs with the data area pointing to the data area of the mapped frames.
  All netlink subsystems assume a linear data area, so for the sake of
  simplicity, the mapped data area is not attached to the paged area but
  to skb->data. This requires introduction of a special skb alloction
  function that just allocates an skb head without the data area. Since this
  is a quite rare use case, I introduced a new function based on __alloc_skb
  instead of splitting it up into head and data alloction. The alternative
  would be to   introduce an __alloc_skb_head and __alloc_skb_data function,
  which would actually be useful for a specific error case in memory mapped
  netlink, but would require a couple of extra instructions for the common
  skb allocation case, so it doesn't really seem worth it.

  In order to get the destination memory area for skb->data before message
  construction, memory mapped netlink I/O needs to look up the destination
  socket during allocation instead of during transmission because the
  ring is owned by the receiveing socket/process. A special skb allocation
  function (netlink_alloc_skb) taking the destination pid as an argument is
  used for this, all subsystems that want to support memory mapped I/O need
  to use this function, automatic fallback to the receive queue happens
  for unconverted subsystems. Dumps automatically use memory mapped I/O if
  the receiving socket has enabled it.

  The visible effect of looking up the destination socket during allocation
  instead of transmission is that message ordering in userspace might
  change in case allocation and transmission aren't performed atomically.
  This usually doesn't matter since most subsystems have a BKL-like lock
  like the rtnl mutex, to my knowledge the currently only existing case
  where it might matter is nfnetlink_queue combined with the recently
  introduced batched verdicts, but a) that subsystem already includes
  sequence numbers which allow userspace to reorder messages in case it
  cares to, also the reodering window is quite small and b) with memory
  mapped transmission batching can be performed in a subsystem indepandant
  manner.

- AF_NETLINK contains flow control for database dumps, with regular I/O
  dump continuation are triggered based on the sockets receive queue space
  and by recvmsg() calls. Since with memory mapped I/O there are no
  recvmsg() calls under normal operation, this is done in netlink_poll(),
  under the assumption that userspace has processed all pending frames
  before invoking poll(), thus the ring is expected to have room for new
  messages. Dumps currently don't benefit as much as they could from
  memory mapped I/O because each single continuation requires a poll()
  call. A more agressive approach seems like a good idea to me, especially
  in case the socket is not subscribed to any multicast groups (IOW only
  receiving explicitly requested data).

Besides that, the memory mapped netlink implementation extends the states
defined by AF_PACKET between userspace and the kernel by a SKIP status, this
is intended for the case that userspace wants to queue frames (specifically
when using nfnetlink_queue, an IDS and stream reassembly, requested by
Eric Leblond) for a longer period of time. The kernel skips over all frames
marked with SKIP when looking or unused frames and only fails when not finding
a free frame or when having skipped the entire ring.

Also noteworthy is memory mapped sendmsg: the kernel performs validation
of messages before accepting and processing them, in order to prevent
userspace from changing the messages contents after validation, the
kernel checks that the ring is only mapped once and the file descriptor
is not shared (in order to avoid having userspace set up another mapping
after the first mentioned check). If either of both is not true, the
message copied to an allocated skb and processed as with regular I/O.

As an example, nfnetlink_queue is convererted to support memory mapped
I/O. Other subsystems that would probably benefit are nfnetlink_log,
audit and maybe ISCSI.

Since the last posting only a minor bug in ring teardown has been fixed.
I'm still working with Florian on solving the nfnetlink_queue ordering
issue, besides that there are no known issues.

Some older performance numbers with nfnetlink_queue from Florian:

nfq recv: regular netlink I/O
mnl recv: mmap'ed netlink I/O
batch: number of batched verdicts

1400 byte UDP packets, 8 cores, NFQUEUE balancing using 4 queues, only
mmap'ed RX, regular TX, userspace running inline Snort with all rules
and preprocessors enabled:

nfq recv, batch 0  1250 MBit total rx
mnl recv, batch 0  1230 MBit total rx
nfq recv, batch 10 1590 MBit total rx
mnl recv, batch 10 1770 MBit total rx

I'll try to get some new numbers soon, including TX and dumps.


The patches are available in a git tree at:

git://github.com/kaber/netlink-mmap master

once git push has finished.


Patrick McHardy (11):
      netlink: add symbolic value for congested state
      net: add function to allocate skbuff head without data area
      netlink: don't orphan skb in netlink_trim()
      netlink: add netlink_skb_set_owner_r()
      netlink: mmaped netlink: ring setup
      netlink: add mmap'ed netlink helper functions
      netlink: implement memory mapped sendmsg()
      netlink: implement memory mapped recvmsg()
      nfnetlink: add support for memory mapped netlink
      netlink: add flow control for memory mapped I/O
      netlink: add documentation for memory mapped I/O

 Documentation/networking/netlink_mmap.txt |  337 ++++++++++++
 include/linux/netfilter/nfnetlink.h       |    2 +
 include/linux/netlink.h                   |   42 ++
 include/linux/skbuff.h                    |    6 +
 net/Kconfig                               |    9 +
 net/core/skbuff.c                         |   31 +-
 net/netfilter/nfnetlink.c                 |    7 +
 net/netfilter/nfnetlink_log.c             |    9 +-
 net/netfilter/nfnetlink_queue_core.c      |    2 +-
 net/netlink/af_netlink.c                  |  849 +++++++++++++++++++++++++++--
 10 files changed, 1250 insertions(+), 44 deletions(-)


^ permalink raw reply	[flat|nested] 20+ messages in thread
* [PATCH RFC 0/11] netlink: memory mapped I/O
@ 2011-09-03 17:26 kaber
  2011-09-03 17:26 ` [PATCH 02/11] net: add function to allocate skbuff head without data area kaber
  0 siblings, 1 reply; 20+ messages in thread
From: kaber @ 2011-09-03 17:26 UTC (permalink / raw)
  To: davem; +Cc: netfilter-devel, netdev

The following RFC patches contain an implementation of memory mapped I/O
for netlink. The implementation is modelled after AF_PACKET memory mapped
I/O with a few differences:

- In order to perform memory mapped I/O to userspace, the kernel allocates
  skbs with the data area pointing to the data area of the mapped frames.
  All netlink subsystems assume a linear data area, so for the sake of
  simplicity, the mapped data area is not attached to the paged area but
  to skb->data. This requires introduction of a special skb alloction
  function that just allocates an skb head without the data area. Since this
  is a quite rare use case, I introduced a new function based on __alloc_skb
  instead of splitting it up into head and data alloction. The alternative
  would be to   introduce an __alloc_skb_head and __alloc_skb_data function,
  which would actually be useful for a specific error case in memory mapped
  netlink, but would require a couple of extra instructions for the common
  skb allocation case, so it doesn't really seem worth it.

  In order to get the destination memory area for skb->data before message
  construction, memory mapped netlink I/O needs to look up the destination
  socket during allocation instead of during transmission because the
  ring is owned by the receiveing socket/process. A special skb allocation
  function (netlink_alloc_skb) taking the destination pid as an argument is
  used for this, all subsystems that want to support memory mapped I/O need
  to use this function, automatic fallback to the receive queue happens
  for unconverted subsystems. Dumps automatically use memory mapped I/O if
  the receiving socket has enabled it.

  The visible effect of looking up the destination socket during allocation
  instead of transmission is that message ordering in userspace might
  change in case allocation and transmission aren't performed atomically.
  This usually doesn't matter since most subsystems have a BKL-like lock
  like the rtnl mutex, to my knowledge the currently only existing case
  where it might matter is nfnetlink_queue combined with the recently
  introduced batched verdicts, but a) that subsystem already includes
  sequence numbers which allow userspace to reorder messages in case it
  cares to, also the reodering window is quite small and b) with memory
  mapped transmission batching can be performed in a subsystem indepandant
  manner.

- AF_NETLINK contains flow control for database dumps, with regular I/O
  dump continuation are triggered based on the sockets receive queue space
  and by recvmsg() calls. Since with memory mapped I/O there are no
  recvmsg() calls under normal operation, this is done in netlink_poll(),
  under the assumption that userspace has processed all pending frames
  before invoking poll(), thus the ring is expected to have room for new
  messages. Dumps currently don't benefit as much as they could from
  memory mapped I/O because each single continuation requires a poll()
  call. A more agressive approach seems like a good idea to me, especially
  in case the socket is not subscribed to any multicast groups (IOW only
  receiving explicitly requested data).

Besides that, the memory mapped netlink implementation extends the states
defined by AF_PACKET between userspace and the kernel by a SKIP status, this
is intended for the case that userspace wants to queue frames (specifically
when using nfnetlink_queue, an IDS and stream reassembly, requested by
Eric Leblond) for a longer period of time. The kernel skips over all frames
marked with SKIP when looking or unused frames and only fails when not finding
a free frame or when having skipped the entire ring.

Also noteworthy is memory mapped sendmsg: the kernel performs validation
of messages before accepting and processing them, in order to prevent
userspace from changing the messages contents after validation, the
kernel checks that the ring is only mapped once and the file descriptor
is not shared (in order to avoid having userspace set up another mapping
after the first mentioned check). If either of both is not true, the
message copied to an allocated skb and processed as with regular I/O.
I'd especially appreciate review of this part since I'm not really versed
in memory, file and process management,

The remaining interesting details are included in the changelogs of the
individual patches and the documentation, so I won't repeat them here.

As an example, nfnetlink_queue is convererted to support memory mapped
I/O. Other subsystems that would probably benefit are nfnetlink_log,
audit and maybe ISCSI, not sure. Since I don't own sufficiently powerful
hardware for real testing, my testcases where based on iperf over loopback.
Depending on the MTU, the latest patchset shows a 900% improvement for
an MTU of 1500 and a roughly 300% improvement for an MTU of 15000.

Jesper is taking benchmarks on real hardware sometime soon, for now I'd
just like to get the basic concept reviewed. An example implementation
for userspace-queueing is available at:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/libmnl-mmap.git

once master.kernel.org is up again. My git tree of the kernel parts
is not up to date anymore, the latest patches show way better
performance in my limited test setup.

Comments and rewiew highly welcome!

Cheers,
Patrick

^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-08-22 22:19 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-20  6:18 [PATCH 00/11] netlink: memory mapped I/O Patrick McHardy
2012-08-20  6:18 ` [PATCH 01/11] netlink: add symbolic value for congested state Patrick McHardy
2012-08-20  6:18 ` [PATCH 02/11] net: add function to allocate skbuff head without data area Patrick McHardy
2012-08-20  6:39   ` Eric Dumazet
2012-08-20  6:41     ` Patrick McHardy
2012-08-20  6:18 ` [PATCH 03/11] netlink: don't orphan skb in netlink_trim() Patrick McHardy
2012-08-20  6:18 ` [PATCH 04/11] netlink: add netlink_skb_set_owner_r() Patrick McHardy
2012-08-20  6:18 ` [PATCH 05/11] netlink: mmaped netlink: ring setup Patrick McHardy
2012-08-20  6:18 ` [PATCH 06/11] netlink: add mmap'ed netlink helper functions Patrick McHardy
2012-08-20  6:18 ` [PATCH 07/11] netlink: implement memory mapped sendmsg() Patrick McHardy
2012-08-20  6:18 ` [PATCH 08/11] netlink: implement memory mapped recvmsg() Patrick McHardy
2012-08-20  6:18 ` [PATCH 09/11] nfnetlink: add support for memory mapped netlink Patrick McHardy
2012-08-20  6:18 ` [PATCH 10/11] netlink: add flow control for memory mapped I/O Patrick McHardy
2012-08-20  6:18 ` [PATCH 11/11] netlink: add documentation " Patrick McHardy
2012-08-20 10:32   ` Jan Engelhardt
2012-08-22 22:19     ` Patrick McHardy
2012-08-22  9:29 ` [PATCH 00/11] netlink: " David Miller
  -- strict thread matches above, loose matches on Subject: below --
2011-09-03 17:26 [PATCH RFC 0/11] " kaber
2011-09-03 17:26 ` [PATCH 02/11] net: add function to allocate skbuff head without data area kaber
2011-09-04  8:12   ` Eric Dumazet
2011-09-07 15:20     ` Patrick McHardy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).