Hi Jon, all,
I did a test by setting two variables condition in range:
- time limit: 2 msecs ... unlimited
- search depth limit (sock's skbs): 2 skbs ... unlimited
With above range settings, a maximum sock's skbs can be enqueued around 12 skbs
regardless of time and search depth limit.
I also combine the test with iperf TCP traffic generated and the result looks
the same.
So, I don't think we need to apply the search depth limit condition and/or
longer timer in this function, just 2msecs is enough.
I guess this result depends on kernel schedule. What are your views?
Regards,
Hoang
> -----Original Message-----
> From: Jon Maloy <jma...@redhat.com>
> Sent: Wednesday, September 1, 2021 7:39 AM
> To: Hoang Huu Le <hoang.h...@dektech.com.au>;
> tipc-discussion@lists.sourceforge.net; Tung Quang Nguyen
> <tung.q.ngu...@dektech.com.au>; Xin Long <lucien....@gmail.com>; Ying Xue
> <ying....@windriver.com>
> Cc: Huy Xuan Nhat Hoang <huy.xn.ho...@dektech.com.au>
> Subject: Re: Strange behavior in socket.c::tipc_sk_enqueue()
>
> Guys,
> After our discussion this morning regarding this problem I gave it some
> more thought.
>
> What if we simply limit the search depth in the receive queue to some
> fix number, 10, 20, 50 or something and return NULL if nothing is found
> within this range. This would be a simple stack counter inside
> tipc_skb_dequeue(), and would cost almost nothing.
>
> If you experiment with this, of course in combination with a max limit
> of some milliseconds as we also discussed, we might obtain acceptable
> results.
>
> What do you think?
>
> ///jon
>
>
> On 28/07/2021 04:04, Hoang Huu Le wrote:
> > 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
