Date: Thu, 29 May 2014 01:57:38 -0300 From: Fred Pedrisa <fredhps10@hotmail.com> To: "'Adrian Chadd'" <adrian@freebsd.org> Cc: 'freebsd-current' <freebsd-current@freebsd.org>, 'Jan Bramkamp' <crest@rlwinm.de> Subject: RES: KQueue vs Select (NetMap) Message-ID: <COL131-DS2CB7D5481FFC762EA6F10B0240@phx.gbl> In-Reply-To: <00d301cf7af9$d5ce5bb0$816b1310$@freebsd.org> References: <COL131-DS24C9EC384D928E5FEB71C3B0240@phx.gbl> <00c301cf7aee$b00caea0$10260be0$@rlwinm.de> <COL131-DS25BDC42287725E7A2D3344B0240@phx.gbl> <CAJ-VmomB=30k1T8u6p1Zd-eQhhkb1FygX87OrTpziHe0gYPC8w@mail.gmail.com> <COL131-DS1365793231D36C08BC1079B0240@phx.gbl> <00d301cf7af9$d5ce5bb0$816b1310$@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, There are 4 threads, and a total of 32 FDs. What do you think ? -----Mensagem original----- De: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@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 <fredhps10@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.chadd@gmail.com [mailto:adrian.chadd@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 <fredhps10@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-current@freebsd.org >> [mailto:owner-freebsd-current@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-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?COL131-DS2CB7D5481FFC762EA6F10B0240>