How is QUIC_MAX_PARTITION_COUNT set?

[jeremyong]

Quick question, I see that QUIC_MAX_PARTITION_COUNT is defined in quicdef.h and that the docs specify this can be set dynamically. However, I don't see a corresponding setting in QUIC_SETTINGs and it seems like the IO threads are spawned before the registration even occurs (as part of the library's initialization routine).

The primary use case for this would be if you need to do some heavier server work and don't want other threads thrashing cache memory on certain cores. It looks like in realtime mode, thread affinity is assigned from 0 counting upwards per partition. Another use case is specifically for client side use where currently all available cores immediately map to two threads on launch (even if you only have one connection intended for lighter usage).

[nibanks]

We have a external storage (i.e. registry) value to control it, but assuming that's not set, we just set it to the processor count (capped to QUIC_MAX_PARTITION_COUNT). See https://github.com/microsoft/msquic/blob/main/src/core/library.c#L304. A QUIC_SETTING from the app isn't going to do anything since we initialize that at the first call to MsQuicOpen.

[jeremyong]

OK I'll look into it when I have time thanks for the responses.

[nibanks]

Sure. Also, in Windows kernel mode, there are no threads created, so you can't control where you get receives from, beyond configuring RSS. I'd prefer to keep that logic consistent across the different abstraction layers.

[jeremyong]

Makes sense, it seems like the easiest change to make is to have quicdef.h set the defines for each param only if they aren't already defined. That way, the user can just override a setting as needed system-wide by defining the macro before including the quic header. Would you be interested in that change?

edit: Oh nevermind these macros get compiled into source haha

[nibanks]

I was just about to say... :) quicdef.h is internal to the library and not exposed to apps.

[jeremyong]

Yea whoops!