Re: [PATCH v9 net-next 2/7] net: add low latency socket poll

From: Eliezer Tamir
Date: Thu Jun 06 2013 - 08:50:52 EST

On 05/06/2013 18:59, Eric Dumazet wrote:
On Wed, 2013-06-05 at 18:46 +0300, Eliezer Tamir wrote:
On 05/06/2013 18:39, Eric Dumazet wrote:
On Wed, 2013-06-05 at 18:30 +0300, Eliezer Tamir wrote:
On 05/06/2013 18:21, Eric Dumazet wrote:

It would also make sense to give end_time as a parameter, so that the
polling() code could really give a end_time for the whole duration of

(You then should test can_poll_ll(end_time) _before_ call to

how would you handle a nonblocking operation in that case?
I guess if we have a socket option, then we don't need to handle none
blocking any diffrent, since the user specified exactly how much time to
waste polling. right?

If the thread already spent 50us in the poll() system call, it for sure
should not call any ndo_ll_poll(). This makes no more sense at this

what about a non-blocking read from a socket?
Right now we assume this means poll only once since the application will
repeat as needed.

maybe add a "once" parameter that will cause sk_poll_ll() to ignore end
time and only try once?

extern bool __sk_poll_ll(struct sock *sk, cycles_t end);

static inline bool sk_poll_ll(struct sock *sk, bool nonblock)
return __sk_poll_ll(sk, nonblock, ll_end_time());

In the poll() code, we should call ll_end_time() once, even if we poll
1000 fds.

Right now we have three uses for sk_poll_ll

1. blocking read - In this case we loop until:
a !skb_queue_empty(&sk->sk_receive_queue)
b !can_poll_ll(end_time)

2. non-blocking read - only try once, ignoring end time.

3. poll/select - for each socket we only try once (nonblock==1),
we loop in poll/select until we are lucky or run out of time.

For 1 we want to loop inside sk_poll_ll() but for 3 we loop in poll/select.

So it seems all we need is for sk_poll_ll() to not call ll_end_time() if nonblock is set.

( something like cycles_t end_time = nonblock ? 0 : ll_end_time(); )

Or we could move out looping in all cases to the calling function.
Does this mean we should push out rcu_read_lock_bh() into the caller
as well?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at