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"
