Wireshark mailing list archives
Re: regarding recv() in mmap calls
From: Guy Harris <guy () alum mit edu>
Date: Thu, 8 Nov 2012 14:25:46 -0800
On Nov 7, 2012, at 10:26 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- regarding recv() in mmap calls abhinav narain (Nov 07)
- Re: regarding recv() in mmap calls Guy Harris (Nov 08)