Re: regarding usage of recv calls in mmap code

[Guy Harris <guy () alum mit edu>]

On Nov 7, 2012, at 10:28 AM, abhinav narain <abhinavnarain10 () gmail com> wrote:

>  I wanted to know why is MSG_PEEK used in the recv() call in mmap code
> and not recvfrom() with MSG_TRUNC flag.
> The reason i am asking is .. because I see my code takes a lot of CPU which is due to more looping, I suppose.
> The flag description for MSG_PEEK shows it doesn't discard the bytes even after reading from the queue.
> Can someone please explain.
> I would like to use recvfrom with MSG_TRUNC .. is that fine ?

The recv() is *not* reading a packet, it's reading an error code.  There shouldn't even *be* any skbuffs to read from 
the socket in the mmapped code path - they should be in the memory-mapped buffer.  That's why it's doing a recv() with 
MSG_PEEK.

The comment "A recv() will give us the actual error code." perhaps doesn't indicate that clearly enough, but that's 
what it's doing.  A poll() that includes the descriptor for the socket should set the POLLERR flag if there's an error 
condition on the descriptor, such as a "this network interface has gone down" indication.  You have to do a recv() from 
the socket to get the error code and clear the error indication so that a subsequent poll() that includes that 
descriptor won't set POLLERR for it.

If that code is being invoked a significant number of times, it means you have a problem - you're getting a lot of 
errors, not packets.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers