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

Reply via email to