Re: [PATCH 00/14]: netlink: memory mapped I/O

[Patrick McHardy <kaber@trash.net>]

On Wed, Apr 17, 2013 at 09:40:46PM +0200, Florian Westphal wrote:
> Patrick McHardy <kaber@trash.net> wrote:
> > The following 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:
> 
> [..]
> 
> > Following are some numbers collected by Florian Westphal based on a
> > slightly older version, which included an experimental patch for the
> > nfnetlink_queue ordering issue.
> 
> I'd like to see a comparision with Eric Dumazets nfnetlink_queue zerocopy
> patch [ ae08ce0021087a5d812d2714fb2a326ef9f8c450, netfilter:
> nfnetlink_queue: zero copy support ].
> 
> The nice thing about that patch is its transparency to userspace, and
> the avoidance of the 'nfnetlink_queue packet reordering' issue.
> 
> Sorry :)

No need to be sorry :) The use cases only partially overlap, the zero copy
(actually single copy, just like mmaped netlink) requires drivers to generate
fragmented skbs, while the mmaped netlink code works in all cases. It also
supports TX and, in case of nfnetlink_queue, modification of the packets.
And it works for all netlink subsystems and is not specific to nfnetlink_queue.

So I think while the nfnetlink_queue zero copy patches are a great idea,
there are still enough unhandled use cases for memory mapped netlink.
 
> Another issue with mmap is the need to preallocate the ring frame size.
> After the gso avoidance change [ no skb_gso_segment calls anymore ],
> we will need to be able to queue GSO/GRO skbs, which makes it necessary to
> cope with 64k payload in the mmap case...

Hmm that might actually also be a problem in the zcopy case for userspace since
the netlink recv buffer sizes are in many cases not that large.