RES: RES: KQueue vs Select (NetMap)

Ok.

Thanks for the enlightenment :)

-----Mensagem original-----
De: owner-freebsd-current_at_freebsd.org
[mailto:owner-freebsd-current_at_freebsd.org] Em nome de Jan Bramkamp
Enviada em: quinta-feira, 29 de maio de 2014 18:55
Para: 'freebsd-current'
Assunto: Re: RES: KQueue vs Select (NetMap)

On 29.05.2014 06:57, Fred Pedrisa wrote:
> Hello,
> 
> There are 4 threads, and a total of 32 FDs. What do you think ?
> 
> -----Mensagem original-----
> De: owner-freebsd-current_at_freebsd.org
> [mailto:owner-freebsd-current_at_freebsd.org] Em nome de Adrian Chadd 
> Enviada em: quinta-feira, 29 de maio de 2014 01:52
> Para: Fred Pedrisa
> Cc: freebsd-current; Jan Bramkamp
> Assunto: Re: KQueue vs Select (NetMap)
> 
> If your netmap thread(s) just have one or two FDs in some low range 
> (say, under FD 8 or 10) - no.
> 
> If you have a whole bunch of active FDs and your netmap threads get 
> FDs that are high - then yes. select() operates on a bitmap of FD 
> numbers. So if your netmap FD is like, FD 8 and it's the highest FD 
> that you're interested in,
> select() only has to scan up to that FD. So it scans up to 8 FDs. If 
> you have a very active program and it has thousands of FDs open, 
> select() has to check all the FDs in the bitmap to see if they're set 
> before getting to your netmap FD.

If your threads use just a handful of small FDs than you shouldn't see any
performance difference between select()/poll() and kqueue(). But
kqueue() can block on multiple event types. This can simply your netmap
threads main loop. It sometimes even enables you to get by with just one
type of main loop instead of multiple different main loops for different
interfaces e.g. one for timers, one for sockets and one for files.
_______________________________________________
freebsd-current_at_freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"