Re: KQueue 0-length UDP packet
Ok, thanks for a clarification! On Tue, Aug 26, 2014 at 1:48 PM, Jan Kokemüller wrote: > Hi, > > > 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: > http://marc.info/?l=freebsd-arch&m=103587526507822&w=2 > 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. > > Cheers, > Jan > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KQueue 0-length UDP packet
Hi, 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: http://marc.info/?l=freebsd-arch&m=103587526507822&w=2 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. Cheers, Jan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KQueue 0-length UDP packet
Hello again! I just realized that the wording was probably a bit off. 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? I am totally fine with the fact that it triggers event on 0-size udp packets, but the behavior itself seems a bit odd, right? Please let me know if this is a bug, and I'll submit a patch. Cheers, Fedor. On Sat, Aug 2, 2014 at 2:57 PM, Fedor Indutny wrote: > After reading that line more carefully, I wonder if this behavior is > really intentional here. > > It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in > terms of > packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` > actually > works there, right? > > Could anyone please comment on this? Is it a bug? > > -- > > Regarding OSX: > > Submitted Apple Bug # 17894467 , with a patch. > > If anyone has friends at Apple who could help getting this in, please let > me know! > > Cheers, > Fedor. > > > On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny wrote: > >> Guess I know the answer: >> >> https://cloudup.com/cCkjLhI4M2r >> >> Basically, OSX is checking `kn_data` and FreeBSD is using >> `so->so_rcv.sb_cc`. >> >> Thank you anyway! >> >> >> On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: >> >>> Hello! >>> >>> I'm trying to figure out, why this code: >>> >>> https://github.com/indutny/0-udp >>> >>> Which basically sends a 0-length UDP packet to a server and polls >>> kqueue events on the server fd. >>> >>> Return 1 kevent on FreeBSD, and blocks indefinitely without >>> returning any events on OSX. >>> >>> So far I could see that FreeBSD and OSX are treating NOTE_LOWAT >>> differently: >>> >>> * >>> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 >>> * >>> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 >>> >>> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using >>> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not >>> involved here by default, I'm failing to see where exactly this >>> event could pass through kqueue filter. >>> >>> Could anyone with UDP and/or KQueue implementation knowledge >>> share some insights with me? >>> >>> Thank you very much! >>> Fedor. >>> >>> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed >>> to the ML) >>> >> >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KQueue 0-length UDP packet
After reading that line more carefully, I wonder if this behavior is really intentional here. It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in terms of packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` actually works there, right? Could anyone please comment on this? Is it a bug? -- Regarding OSX: Submitted Apple Bug # 17894467 , with a patch. If anyone has friends at Apple who could help getting this in, please let me know! Cheers, Fedor. On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny wrote: > Guess I know the answer: > > https://cloudup.com/cCkjLhI4M2r > > Basically, OSX is checking `kn_data` and FreeBSD is using > `so->so_rcv.sb_cc`. > > Thank you anyway! > > > On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: > >> Hello! >> >> I'm trying to figure out, why this code: >> >> https://github.com/indutny/0-udp >> >> Which basically sends a 0-length UDP packet to a server and polls >> kqueue events on the server fd. >> >> Return 1 kevent on FreeBSD, and blocks indefinitely without >> returning any events on OSX. >> >> So far I could see that FreeBSD and OSX are treating NOTE_LOWAT >> differently: >> >> * >> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 >> * >> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 >> >> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using >> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not >> involved here by default, I'm failing to see where exactly this >> event could pass through kqueue filter. >> >> Could anyone with UDP and/or KQueue implementation knowledge >> share some insights with me? >> >> Thank you very much! >> Fedor. >> >> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed >> to the ML) >> > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: KQueue 0-length UDP packet
Guess I know the answer: https://cloudup.com/cCkjLhI4M2r Basically, OSX is checking `kn_data` and FreeBSD is using `so->so_rcv.sb_cc`. Thank you anyway! On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: > Hello! > > I'm trying to figure out, why this code: > > https://github.com/indutny/0-udp > > Which basically sends a 0-length UDP packet to a server and polls > kqueue events on the server fd. > > Return 1 kevent on FreeBSD, and blocks indefinitely without > returning any events on OSX. > > So far I could see that FreeBSD and OSX are treating NOTE_LOWAT > differently: > > * > https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 > * > https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 > > FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using > SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not > involved here by default, I'm failing to see where exactly this > event could pass through kqueue filter. > > Could anyone with UDP and/or KQueue implementation knowledge > share some insights with me? > > Thank you very much! > Fedor. > > (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed > to the ML) > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
KQueue 0-length UDP packet
Hello! I'm trying to figure out, why this code: https://github.com/indutny/0-udp Which basically sends a 0-length UDP packet to a server and polls kqueue events on the server fd. Return 1 kevent on FreeBSD, and blocks indefinitely without returning any events on OSX. So far I could see that FreeBSD and OSX are treating NOTE_LOWAT differently: * https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 * https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not involved here by default, I'm failing to see where exactly this event could pass through kqueue filter. Could anyone with UDP and/or KQueue implementation knowledge share some insights with me? Thank you very much! Fedor. (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed to the ML) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
