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-curr...@freebsd.org [mailto:owner-freebsd-curr...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RES: RES: KQueue vs Select (NetMap)
Ok. Thanks for the enlightenment :) -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@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-curr...@freebsd.org [mailto:owner-freebsd-curr...@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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
KQueue vs Select (NetMap)
Hey Guys, How does kQueue performs over select with netmap ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KQueue vs Select (NetMap)
On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RES: KQueue vs Select (NetMap)
Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KQueue vs Select (NetMap)
The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RES: KQueue vs Select (NetMap)
Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: KQueue vs Select (NetMap)
On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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. So yes. kqueue() is actually rather nice. -a On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RES: KQueue vs Select (NetMap)
Hello, There are 4 threads, and a total of 32 FDs. What do you think ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@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. So yes. kqueue() is actually rather nice. -a On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RES: KQueue vs Select (NetMap)
On Thursday 29 May 2014 01:57:38 Fred Pedrisa wrote: Hello, There are 4 threads, and a total of 32 FDs. What do you think ? I think it is time for you to try it and find out... I suspect it wouldn't make much difference at all if you just implement select semantics with kqueue. -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@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. So yes. kqueue() is actually rather nice. -a On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. signature.asc Description: This is a digitally signed message part.
Re: RES: KQueue vs Select (NetMap)
what he said. -a On 28 May 2014 22:02, Peter Wemm pe...@wemm.org wrote: On Thursday 29 May 2014 01:57:38 Fred Pedrisa wrote: Hello, There are 4 threads, and a total of 32 FDs. What do you think ? I think it is time for you to try it and find out... I suspect it wouldn't make much difference at all if you just implement select semantics with kqueue. -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@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. So yes. kqueue() is actually rather nice. -a On 28 May 2014 21:48, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Ok, but in practice, is there any performance gain by moving from select to kQueue implementation ? Or is it not significant at all ? -Mensagem original- De: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] Em nome de Adrian Chadd Enviada em: quinta-feira, 29 de maio de 2014 01:46 Para: Fred Pedrisa Cc: Jan Bramkamp; freebsd-current Assunto: Re: KQueue vs Select (NetMap) The advantage is being able to include it in the rest of a kqueue IO loop where it's doing other things. -a On 28 May 2014 20:53, Fred Pedrisa fredhp...@hotmail.com wrote: Hello, Yes, but kqueue support was added in recent commits as it says in the netmap changelog, is there any advantage ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Jan Bramkamp Enviada em: quinta-feira, 29 de maio de 2014 00:30 Para: freebsd-current@freebsd.org Assunto: Re: KQueue vs Select (NetMap) On 29.05.2014 03:04, Fred Pedrisa wrote: Hey Guys, How does kQueue performs over select with netmap ? You are asking for a comparison between apples and oranges. Netmap is an API for high performance access to the low-level features of modern NICs. It works on batches of frames in hardware queues. The kqueue() and kevent() system calls are an event notification API. It is mostly used by application dealing with a large amount of non-blocking sockets (or other file descriptors). It reduces overhead inherent in select() and poll() by preserving state between calls. It also supports multiple types of events (read ready, write ready, timer expired, async i/o, etc.). Afaik the netmap pseudo-device supports only select() and poll(). This is no performance problem because every thread will only deal with a small number of file descriptors to netmap devices. Netmap is designed to bypass the FreeBSD IP stack (for most frames). Kqueue is designed to scale to many sockets per process within the FreeBSD IP stack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
