Hi Jon,
Let's enjoy your vacation.
Our new team member (CCed) will take a look at it.
Regards,
Hoang
> -----Original Message-----
> From: Jon Maloy <jma...@redhat.com>
> Sent: Wednesday, July 28, 2021 6:20 AM
> To: tipc-discussion@lists.sourceforge.net; Tung Quang Nguyen
> <tung.q.ngu...@dektech.com.au>; Hoang Huu Le
> <hoang.h...@dektech.com.au>; Xin Long <lucien....@gmail.com>; Ying Xue
> <ying....@windriver.com>
> Subject: Strange behavior in socket.c::tipc_sk_enqueue()
>
> I did by accident discover a strange behavior in the function
> tipc_sk_enqueue:
>
>
> 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
