RES: KQueue vs Select (NetMap)

[Fred Pedrisa]

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 at gmail.com [mailto:adrian.chadd at 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 at 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 at freebsd.org
> [mailto:owner-freebsd-current at freebsd.org] Em nome de Jan Bramkamp 
> Enviada em: quinta-feira, 29 de maio de 2014 00:30
> Para: freebsd-current at 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 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"
>
> _______________________________________________
> 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"