Hi David, On Tue, Nov 24, 2015, at 23:25, David Miller wrote: > From: Florian Westphal <f...@strlen.de> > Date: Tue, 24 Nov 2015 23:22:42 +0100 > > > Yes, I get that point, but I maintain that KCM is a strange workaround > > for bad userspace design. > > I fundamentally disagree with you. > > And even if I didn't, I would be remiss to completely dismiss the > difficulty in changing existing protocols and existing large scale > implementations of them. If we can facilitate them somehow then > I see nothing wrong with that. > > Neither you nor Hannes have made a strong enough argument for me > to consider Tom's work not suitable for upstream. > > Have you even looked at the example userspace use case he referenced > and considered the constraints under which it operates? I seriously > doubt you did.
If you are referring to thrift and tls framing, yes indeed, I did. I have experience in google protocol buffers and once cared about an in-house RPC implementation. All I learned is that this approach is prone to starving or building up huge messages in kernel space. That is why xml streaming in form of StAX from the Java world is used more and more and even Apache Jackson does provide a streaming API for JSON which I once used because JSON messages streamed as hash tables got too big and were prone to starve. Even user space needs to be careful what sizes of messages they accept otherwise DoS attacks are possible and jvms with small heaps are getting OutOfMemoryExceptions. This is the same in other high level languages, non-GCed (or without copying garbage collector) languages just reallocate and cause fragmentation in the long term. Even keeping multiple 16MB chunks for HTTP/2 in the kernel heap so that user space can read them in on go seems very much bad in my opinion. Neither of all those approaches delimit datagrams by "read() barriers". I think the alternatives should be tried. I think this framework is only applicable to a small fractions of RPC systems. Thanks for following up, :) Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
