Honoring SO_RCVLOWAT in proto_ops.poll methods

* Honoring SO_RCVLOWAT in proto_ops.poll methods
@ 2008-09-20 21:42 lkml
  2008-09-20 22:21 ` David Miller
  0 siblings, 1 reply; 20+ messages in thread
From: lkml @ 2008-09-20 21:42 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 20+ messages in thread