netdev - Re: [PATCH -next] net: preserve geometry of fragment sizes when forwarding

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]

Message-Id: <20150518.165550.359134808190719687.davem@davemloft.net>
Date:	Mon, 18 May 2015 16:55:50 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	fw@...len.de
Cc:	netdev@...r.kernel.org, hannes@...essinduktion.org,
	edumazet@...gle.com, herbert@...dor.apana.org.au
Subject: Re: [PATCH -next] net: preserve geometry of fragment sizes when
 forwarding

From: Florian Westphal <fw@...len.de>
Date: Mon, 18 May 2015 22:40:49 +0200

> But, to the best of my understanding, what you ask will push a lot of
> non-trivial code into the kernel for no functional gain over
> what has been proposed.

The functional gain is that we stop linearizing the packet, which
involves memory allocation and copying the entire packet.

I am very confident that the performance gains would be non-trivial
and quite measurable.

You'd also be able to trivially respect the geometry of the original
incoming packet stream.

Every objection has been of the form "this special case" (this time
SIP) is not easy.

If I were doing this, I would implement something that handles the
normal cases properly.  And then take it from there.

If you try to imagine the totality of it and all the edge cases
and details from the beginning, yes it will look impossible.
--
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