On Tue, Nov 24, 2015 at 8:25 AM, Florian Westphal <f...@strlen.de> wrote: > 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. > Well, this is the sort of thing that multi threaded applications do.
> Now, arguably, maybe the requirements of Toms use case are restricted > /cannot be avoided. > > But that still begs the question: Why should mainline care? > I have no idea. I guess it's the same reason that mainline would care about RDS, iSCSI, FCOE, RMDA, or anything in that nature. No one is being forced to use any of this. > 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? Obviously we are looking forward TLS+KCM. But it does open up a bunch of other possibilities. -- 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
