Messages in this thread | | | Date | Sat, 20 Sep 2008 16:42:29 -0500 | From | lkml@pengaru ... | Subject | Honoring SO_RCVLOWAT in proto_ops.poll methods |
| |
Hello lkml,
I have a need for select/poll/epoll_wait to block on sockets which have unread data sitting in the receive buffer with a quantity less than specified via setsockopt() w/SO_RCVLOWAT, not less than one like the current implementation.
Upon looking at the code in net/ipv4/tcp.c it doesn't look like this would be difficult to support. Something along the lines of changing the function tcp_poll() of version 2.6.26.5 from doing this:
394 if ((tp->rcv_nxt != tp->copied_seq) && 395 (tp->urg_seq != tp->copied_seq || 396 tp->rcv_nxt != tp->copied_seq + 1 || 397 sock_flag(sk, SOCK_URGINLINE) || !tp->urg_data)) 398 mask |= POLLIN | POLLRDNORM;
to this:
394 if ((tp->rcv_nxt != tp->copied_seq) && 395 (tp->urg_seq != tp->copied_seq || 396 tp->rcv_nxt > tp->copied_seq + sk->sk_rcvlowat || 397 sock_flag(sk, SOCK_URGINLINE) || !tp->urg_data)) 398 mask |= POLLIN | POLLRDNORM;
I imagine it's similarly simple for the other socket types. Am I missing something? Is there a technical reason why Linux only blocks in read/recv but not the poll with respect to the SO_RCVLOWAT setting?
For those interested the application is basically doing:
1: Wait for input on active sockets with epoll_wait() 2: Recv() data off the eventful sockets with MSG_PEEK flag, parse contents looking for specific keyword and value from buffer. 3: If buffer is too short call setsockopt() with SO_RCVLOWAT parameter set greater than what recv() with MSG_PEEK returned.
Repeat @ 1 until finding what's needed or shutdown/error/timeout.
Once the value is parsed it's used as an address to locate (with a db lookup) a path which would be a unix domain socket for passing the socket descriptor through. The unrelated process at the other end needs to accept the descriptor and use it as if no other program mucked with it hence the MSG_PEEK magic.
As-is I must basically tie up threads in blocked recv() calls after increasing SO_RCVLOWAT if the first recv() peek falls short. This solution obviously doesn't scale well.
Thanks, Vito Caputo
| |