static void tipc_sk_enqueue(struct sk_buff_head *inputq, struct sock *sk, u32 dport, struct sk_buff_head *xmitq) { struct tipc_sock *tsk = tipc_sk(sk); unsigned long time_limit = jiffies + 2; struct sk_buff *skb; unsigned int lim; atomic_t *dcnt; u32 onode; while (skb_queue_len(inputq)) { if (unlikely(time_after_eq(jiffies, time_limit))) return; [...] } } At the moment we call time_after_eq() the two jiffies often have already passed, and the skb is not dequeued. I noticed that tipc_sk_rcv() may call tipc_sk_enqueue() with the same skb dozens of times before the buffer can be delivered further upwards in the stack. Needless to say that this cannot be good for performance. I believe the value of 2 jiffies was hard coded at a time when machines were slower, and a jiffie represented a much longer time interval. Now it is clearly too short, and should be replaced with something longer and more consisten, e.g. msec_to_jiffies(2). Can anybody look into this? Also, I will be on vacation the next two weeks, which means we should cancel the bi-weekly meeting next Tuesday. ///jon _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
I did by accident discover a strange behavior in the function
tipc_sk_enqueue:
- [tipc-discussion] Strange behavior in socket.c::tipc_sk_enque... Jon Maloy
- Re: [tipc-discussion] Strange behavior in socket.c::tipc... Hoang Huu Le
- Re: [tipc-discussion] Strange behavior in socket.c::... Jon Maloy
- Re: [tipc-discussion] Strange behavior in socket... Hoang Huu Le
- Re: [tipc-discussion] Strange behavior in so... Jon Maloy
- Re: [tipc-discussion] Strange behavior ... Hoang Huu Le
- Re: [tipc-discussion] Strange behav... Jon Maloy