multipath-tcp / mptcp

⚠️⚠️⚠️ Deprecated 🚫 Out-of-tree Linux Kernel implementation of MultiPath TCP. 👉 Use https://github.com/multipath-tcp/mptcp_net-next repo instead ⚠️⚠️⚠️
https://github.com/multipath-tcp/mptcp_net-next
Other
888 stars 335 forks source link

Out of Order queue in meta-level using RBTREE is always same #394

Closed dhawaskar closed 4 years ago

dhawaskar commented 4 years ago

Hi,

In old MPTCP (up to v92) the OFO was maintained as queue and the function skb_queue_len(&meta_tp->out_of_order_queue) could give the OFO length. Now that OFO is implemented as RB tree in v95, I want to know the OFO length by simply counting the number of nodes in RB Tree.

I put this function in include/linux/skbuff.h and use it to count the OFO length.

static inline __u32 mptcpofo_tree_len(struct rb_node *root){
        int count=0;
        if(root){
                count++;
                count+=mptcpofo_tree_len(root->rb_left);
                count+=mptcpofo_tree_len(root->rb_right);
        }
        return count;

}

But every time I get the OFO length in mptcp_input.c file in function : static int mptcp_queue_skb(struct sock *sk)

After the the line: tcp_data_queue_ofo(meta_sk, tmp1);

I do not see the number being continuously incremented untill the rbtree purge is called, it is same some time and incremented some time. Is it because RB tree do not allow the duplicate nodes?

So I want to know how to measure OFO length at meta-level. Is my implementation is wrong? Sandesh

dhawaskar commented 4 years ago

Here is where, the MPTCP lOFO length is printed: OFO is decreased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is increased 44 OFO is decreased 43 OFO is decreased 42 OFO is decreased 41 OFO is decreased 40 OFO is decreased 39 OFO is decreased 38 OFO is decreased 37 OFO is increased 37 OFO is increased 37 OFO is increased 37 OFO is increased 37 OFO is increased 37 OFO is increased 37 OFO is increased 37 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38 OFO is increased 38

As you can see every print statement after line tcp_data_queue_ofo(meta_sk, tmp1) should give incremented value instead it gives same value.

Sandesh

cpaasch commented 4 years ago

The TCP/MPTCP-stack is trying to coalesce segments in the out-of-order queue if they are adjacent.

I guess that is why you are not seeing what you are expecting.

matttbe commented 4 years ago

Maybe you can use eBPF to increase and decrease a counter each time a new item is added/removed.

dhawaskar commented 4 years ago

The TCP/MPTCP-stack is trying to coalesce segments in the out-of-order queue if they are adjacent.

I guess that is why you are not seeing what you are expecting.

Thank you. I could use the function below to get the overall OFO bytes, I can see there is increase . unsigned int sandy_tree_bytes(struct rb_root root) { struct rb_node p = rb_first(root); unsigned int sum = 0;

    while (p) {
            struct sk_buff *skb = rb_entry(p, struct sk_buff, rbnode);
            sum+=skb->truesize;
            p = rb_next(p);
    }
    return sum;

}

dhawaskar commented 4 years ago

What confusion is how can this actually account overall memory allocated and give continuous increase where in number of nodes are not?

cpaasch commented 4 years ago

Yes, skb->truesize is what you want to track

dhawaskar commented 4 years ago

okay thank you for the confirmation.