David Miller <da...@davemloft.net> wrote: > From: Florian Westphal <f...@strlen.de> > Date: Tue, 24 Nov 2015 16:27:44 +0100 > > > Aside from Hannes comment -- KCM seems to be tied to the TLS work, i.e. > > I have the impression that KCM without ability to do TLS in the kernel > > is pretty much useless for whatever use case Tom has in mind. > > I do not get this impression at all. > > Tom's design document in the final patch looks legitimately what the > core use case is.
You mean https://patchwork.ozlabs.org/patch/547054/ ? Its a well-written document, but I don't see how moving the burden of locking a single logical tcp connection (to prevent threads from reading a partial record) from userspace to kernel is an improvement. If you really have 100 threads and must use a single tcp connection to multiplex some arbitrarily complex record-format in atomic fashion, then your requirements suck. Now, arguably, maybe the requirements of Toms use case are restricted /cannot be avoided. But that still begs the question: Why should mainline care? Once its in, next step will be 'my single tcp connection that I use for multiplexing via KCM now has requirement to use TLS'. How far are you willing to take the KCM concept? -- 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
