3

I'm using NETLINK socket to receive NETLINK_ROUTE notifications in a user-space application.

I understand that ENOBUFS error is returned from recvmsg() when:

  1. The user-space application is too slow to handle all the NETLINK messages that the kernel subsystem sends at a give rate.
  2. The queue that is used to store messages that go from kernel to user-space is too small.

Now, am sure that the second point does not happen in my case since am able to receive certain notifications initially without any error.

After a period of time, I get the ENOBUFS error.

My doubt is that when the recvmsg() returns ENOBUFS:

  • Will it also fill and return the available messages that are still in the socket buffer?
  • Or will it just return ENOBUFS?

Because, according to my understanding, if the socket buffer is full and NETLINK cannot write any more notifications onto the socket buffer, then it means there are still messages that need to be read from the socket.

Chris Petrus
  • 193
  • 1
  • 3
  • 15
  • 1
    That's not right. The system has run out of some other kind of buffer. Never understood what kind, or why it would need more buffers transferring existing data from an existing socket receive buffer to the application's existing buffer, but there it is. Anyway if you get it in association with a return value of -1 instead of a positive message length, nothing has been transferred. – user207421 Aug 23 '17 at 18:39
  • 1
    @EJP Indeed, I am getting a return value of -1. So can I assume ENOBUFS is like a caution to me that the buffer is full and that I will have to continue doing recvmsg() to free some of the buffers? In other words, I just wanted to know that I won't be missing any messages from being processed before I go over for another recvmsg(). Alternatively, I also have the option of increasing the socket buffer size. – Chris Petrus Aug 23 '17 at 18:50
  • 1
    No, you can assume what I said, that the system is out of some *other* kind of buffer. You can further assume that there is *something* in the socket receiver buffer, as otherwise you would have blocked or got EAGAIN/EWOULDBLOCK. I don't see any reason to assume the socket receive buffer is full. That's an error to the *sender*, not the receiver, and it causes packet drops. – user207421 Aug 24 '17 at 00:08
  • Maybe @DavidSchwartz can enlighten us further, or correct me. – user207421 Aug 24 '17 at 00:10
  • Or @RemyLebeau. – user207421 Aug 24 '17 at 02:28
  • @ChrisPetrus did you find the answer? In my case I do `poll()` (with timeout) before doing `recv()`. Since `POLLERR` is set in `poll()`'s `revents`, I check with `getsockopt()` if `ENOBUFS` has occurred on socket FD. But then I do not want to block on `recv()` if there is no message to read. – Irfan Latif Jul 17 '23 at 17:34

0 Answers0