3 ms·

(Tailscale employee) We certainly didn't try to make it click-baity. The point of the title is that people assume that Tailscale was slower than kernel wiregua

(Tailscale employee) We certainly didn't try to make it click-baity. The point of the title is that people assume that Tailscale was slower than kernel wireguard because the kernel must be intrinsically faster somehow. The point of the blog post is to say, "no, code can run fast on either side... you just have to cross the boundary less." The blog post is all about how we then cross that boundary less, using a less obvious kernel interface.

cycomanic 4y ago
Just some feedback, that's not what I expected from the title and I would agree with the previous poster that the title is a little (quite minor though) clickbaity.
wpietri 4y ago
For what it's worth, the combination of the source and the title made sense to me, so I think it's fine as is.
- dotancohen 4y ago
  The purpose of the title is to summarize, enabling the reader to decide if the article is relevant and interesting to him. If the title presents a situation that seems more dire, urgent, or relevant then the article, then it is written to entice click through rates, even if it makes sense after having read the article.
  - wpietri 4y ago
    Yes, thanks, I understood what a title is for. And I'm saying this one was fine for me.
karmakaze 4y ago
Thanks for the clarifying reply. I thought most folks who cared knew it was about context switches and not speed on one side vs the other. Now I'm really interested to read the full article.
dekhn 4y ago
I would have titled it something like "Userspace is slow if you do lots of context switches/userspace transitions" (if I understand the point of the post)... but that's sort of been known for a while now. I think the novelty of this comes mainly from the inversion of control in your design, and the post explicitly points out that it's likely every single performance improvement in userspace could be equalled by kernelspace, and likely, exceeded by kernelspace. What's really crazy is that we're talking about userspace and 10Gbit, which shows that CPUs, busses, and the interface protocols have all been scaling well with interface speeds! Personally I don't ever increase MTU, even if there's a significant performance win, since I prefer to not place our oncall in a situation where they have to debug an outage due to MTU incompability.

cycomanic 4y ago

Just some feedback, that's not what I expected from the title and I would agree with the previous poster that the title is a little (quite minor though) clickbaity.

wpietri 4y ago

For what it's worth, the combination of the source and the title made sense to me, so I think it's fine as is.

dotancohen 4y ago
The purpose of the title is to summarize, enabling the reader to decide if the article is relevant and interesting to him. If the title presents a situation that seems more dire, urgent, or relevant then the article, then it is written to entice click through rates, even if it makes sense after having read the article.
- wpietri 4y ago
  Yes, thanks, I understood what a title is for. And I'm saying this one was fine for me.

karmakaze 4y ago

Thanks for the clarifying reply. I thought most folks who cared knew it was about context switches and not speed on one side vs the other. Now I'm really interested to read the full article.

dekhn 4y ago

I would have titled it something like "Userspace is slow if you do lots of context switches/userspace transitions" (if I understand the point of the post)... but that's sort of been known for a while now. I think the novelty of this comes mainly from the inversion of control in your design, and the post explicitly points out that it's likely every single performance improvement in userspace could be equalled by kernelspace, and likely, exceeded by kernelspace. What's really crazy is that we're talking about userspace and 10Gbit, which shows that CPUs, busses, and the interface protocols have all been scaling well with interface speeds! Personally I don't ever increase MTU, even if there's a significant performance win, since I prefer to not place our oncall in a situation where they have to debug an outage due to MTU incompability.