Hi,
In tcp_sendmsg() if we find that we cannot pack any
more data in the skbuff which is at the tail of the
sk->sk_write_queue, we call tcp_mark_push() which
sets tp->pushed_seq = tp->write_seq.
The relevant code fragment is
--------------- START --------------------
if (can_coalesce(skb, i, page, off) &&
off != PAGE_SIZE) {
/* We can extend the last page
* fragment. */
merge = 1;
} else if (i == MAX_SKB_FRAGS ||
(!i &&
!(sk->sk_route_caps & NETIF_F_SG))) {
/* Need to add new fragment and cannot
* do this because interface is non-SG,
* or because all the page slots are
* busy. */
tcp_mark_push(tp, skb);
goto new_segment;
} else if (page) {
-------------- END ------------------------
After this we continue and allocate a fresh skbuff and
start packing more user data in that. Now, assuming
that user has enough data to send, the new skbuff
will also be filled till it has mss_now worth of data
and then we reach the following code fragment.
--------------- START --------------------
if (forced_push(tp)) {
tcp_mark_push(tp, skb);
__tcp_push_pending_frames(sk, tp, mss_now,
TCP_NAGLE_PUSH);
} else if (skb == tp->send_head)
tcp_push_one(sk, mss_now);
-------------- END ------------------------
I believe the check for forced_push() implements
sender side SWS avoidance, to see if we can send at
least half the maximum window advertised by the peer.
If so, then why does this check for tp->write_seq to
be more than tp->pushed_seq+1/2(maximum window
advertised by peer), where tp->pushed_seq is _not_
pointing to the first byte that we can send (since
tcp_mark_push in the
first code fragment above moved it to the end of the
last skbuff).
IOW we don't have tp->write_seq-tp->pushed_seq worth
of data to send, but,
tp->write_seq-tp->pushed_seq+skb->len, where skb is
the last skb for which we called tcp_mark_push.
Have I misunderstood something ?
Thanks,
tomar
___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
