is there a way to show which cpu id is processing the current thread in a tcp server?

[kolinfluence]

is there a way to show which cpu id is processing the current thread in a tcp server?

[glommer]

what exactly do you want to know? the logical cpu id ?

You shouldn't need anything special from the framework to do that. Syscalls like getcpu() will get the info you need, and I am sure there is some Rust package exposing that. Keep in mind though that unless the thread is pinned, it can move to different CPUs.

[kolinfluence]

@glommer glommer
how do u pin the thread?

i'm trying to process ip address by cpu ID. e.g. hashed(123.123.123.123)%cpunum == cpuid to process this ip only

[glommer]

You can pin the thread by creating an executor with a fixed placement:
https://docs.rs/glommio/latest/glommio/#pinned-threads

However, in your case, why not use the thread_id or executor_id instead?

You can get the local executor like this:https://docs.rs/glommio/latest/glommio/fn.executor.html

and then get the id from the ExecutorProxy.

This is better because it will always be 0,1,2,3, etc, whereas the CPU IDs can have gaps.

[kolinfluence]

@glommer totally new to glommio.
how do you pin specific ip addresses for processing by specific cpu id only? i've checked the references u mentioned but cant seem to wrap my head around how to implement it.

hash(ip) % [total number of cpus] = cpuid (which is used to process that ip only)

can provide some sample code?

[glommer]

I don't think that's doable in the current incarnation of glommio - and for the record, it's a problem that we battled for years on seastar.

If you can listen on different ports, and then map a port to a CPU, then that's easy: just have different threads listening on the different ports.

But what you usually want is to listen on a single port, and then split the traffic across multiple CPUs. The problem here is that when you call accept() on multiple servers, you have no idea where the kernel will pass the connection. It can pass it anywhere.

What you can do is accept the connection, then figure out where you want to handle it, and then move the data to a new executor (which you can do with shared channels), but this is complex, and this transfer itself can be quite expensive (meaning it will not work well at all for short lived connections)

[bryandmc]

You can use ebpf to program where the kernel sends the connections on accept and SO_REUSEPORT @glommer -- that seems like the situation you are describing.. Examples are hard to find but it's already supported on many kernels.

EDIT: found one example that's pretty good: https://github.com/network-analytics/ebpf-loadbalancer