DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS and UnsafePreferInlineScheduling Support

[Rodrigo-Andrade]

I have being using this with great results for more than a year now, any plans for making this more "official"?

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[stephentoub]

I have being using this with great results

Can you share more details?

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have being using this with great results for more than a year now, any plans for making this more "official"?

Author:	Rodrigo-Andrade
Assignees:	-
Labels:	area-System.Net.Sockets, untriaged
Milestone:	-

[Rodrigo-Andrade]

Can you share more details?

I talked a bit about that here:
#44449

But long story short: since the change of how sockets queue work in linux, my app had some performance regressions.
After enabling both flags, app performance doubled by avoiding queuing work in the threadpool.

[halter73]

At least for UnsafePreferInlineScheduling in Kestrel, the concern is this could cause worse performance and possibly even deadlocks given blocking code. I assume there are similar concerns for DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS.

Kestrel defaults to AllowSynchronousIO being false, but that just prevents calls to HttpContext.Request.Body.Read(...) and not HttpContext.Request.Body.ReadAsync(...).Result and other similar patterns. Even blocking on something like a database transaction or an outgoing HTTP request from a request handler could be a big problem if Kestrel's Socket transport doesn't dispatch to the thread pool.

[Rodrigo-Andrade]

Yes, and i had this problem (deadlocks), that actually led to improvements as some code paths were silently blocking.
But i am not proposing it to be the default, just that it is a legitimate option, right now it's my understanding that it's just experimental and can be pulled at any moment.

[karelz]

Triage: Currently we do not have plans to productize it, but we want to do more investigation in 7.0 + collect feedback from users who use, so we will keep it open.

[ShreyasJejurkar]

Please consider making this option as supported instead of experiment if not on by default.