What I wanted to ask is: why does FreeBSD kqueue implementation treat
`SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
data size for filtering out events?

It looks like SO_RCVLOWAT refers to the number of bytes in the socket buffer, not raw packet bytes. In the case of an arriving UDP packet there is always a 'struct sockaddr' in the buffer that contains the source address/port of the message. For IPv4 this is 16 bytes and for IPv6 28 bytes. I think this is intended behavior, as this is data you can "read" with recvfrom or recvmsg.

POSIX says "Receive calls may still return less than the low water mark if an error occurs, a signal is caught, or the type of data next in the receive queue is different from that returned (for example, out-of-band data)." So in this case this data is address data.

On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. The semantics were changed in 2002:
The value you get in 'data' also refers to the number of protocol data bytes available.

I've had a look at how OpenBSD handles this. It returns the number of protocol data bytes with "ioctl(s, FIONREAD, &len)" but the number of bytes in the socket buffer in the 'data' member of kevent, so exactly the other way around compared to FreeBSD. SO_RCVLOWAT works still the same, though.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to