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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Apr 2013 12:27:39 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Florian Westphal <fw@...len.de>
Cc:	davem@...emloft.net, netfilter-devel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 00/14]: netlink: memory mapped I/O

On Wed, Apr 17, 2013 at 09:40:46PM +0200, Florian Westphal wrote:
> Patrick McHardy <kaber@...sh.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html