Re: Best practice for accepting TCP connections on multicore?

Hi,

I'm working on exactly this with the RSS support that's in the tree.

The vague design I have in mind is to have one bound thread per RSS
allocated CPU, and then put a listen TCP (and later UDP) socket in
each thread.

Then the accept path in the TCP/PCB code will do a lookup in the
CPU-local PCBGROUP table first to see if there's a local listen socket
in that table that's local to that CPU. If so, the request will go to
that socket.

I'll later add support for multiple sockets listening on the same
IP:PORT entry, so you can have multiple threads load balanced (eg on
the same CPU, or a small CPU set on a core local to that NIC, etc.)
But that'll have to come later - it requires a slightly larger
overhaul of how listen entries work in that table.

I have a patchset that works and I'll be slowly merging it into -HEAD
over the next week.

Thanks,

-a

On 6 June 2014 16:00, Daniel Janzon <janzon@gmail.com> wrote:
> Hi,
>
> What is the best practice (performance-wise) for dispatching new TCP
> connections to different threads in order to make use of multiple cores?
>
> Is there any better way than doing the accept() call in one thread and then
> dispatch it to a thread on another core with any user space method?
>
> Conceivably one should be able to perform the accept() call from several
> threads but using the same socket and let the kernel distribute the
> incoming connections using some kind of hash or round robin.
>
> Regards,
> Daniel
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"