Dave,
On Tue, 6 Jul 2004, David S. Miller wrote:
>
> This code path is rare and unusual.
>
> It could occur because of some bizarre combination of sendfile()
> and sendmsg() calls while TCP_CORK has been set on the socket.
> You would need to sendfile a byte from MAX_SKB_FRAGS - 1 different
> unique pages, then make a sendmsg() call before that packet gets
> sent out. That's beyond abnormal. :-)
You are right in saying that, this particular path will be very _rarely_
taken. One not-so-rare case might be, if we are doing sends of say 65K and
MAX_SKB_FRAGS is set to 6 (which I believe is the case for 2.4). Then,
after packing ~24K in the first SKB, we do the tcp_mark_push() (the rare
one) and then allocate another SKB and then we hit this problem.
This will _only_ be a problem if TSO is backported to 2.4, since such a
large MSS is possible only in the case of TSO enabled outgoing device.
So we can say that this is a non-issue.
>
> So I believe that the tcp_mark_push() invocation that actually
> occurs in practice is the other one in this function:
>
>
> if (forced_push(tp)) {
> tcp_mark_push(tp, skb);
> __tcp_push_pending_frames(sk, tp, mss_now, TCP_NAGLE_PUSH);
Even with this we can run into the same problem.
Consider our same old example.
Suppose we come here for the first time for skb1, and suppose skb1 had
enough data (more than half the max window) so that the forced_push()
check passes. Now tcp_mark_push sets
tp->pushed_seq = tp->write_seq = skb1->end_seq.
Suppose for some reason __tcp_push_pending_frames could not send skb1, as
tcp_send_test failed. A good candidate is the following check.
((tcp_packets_in_flight(tp) < tp->snd_cwnd)
which is not so rare or even tcp_write_xmit failing b'cos of device
congestion.
Now when we come into this check for the second time, for skb2 this time,
the forced_push() check might fail if "skb2->len < tp->max_window>>1",
though we have skb1->len+skb2->len worth of data queued, which can
probably be more than tp->max_window/2.
I feel that even this is also a non-issue. This is b'cos we are trying to
address a problem in which we are not sending data even though sender side
SWS allows us; in all the above cases where __tcp_push_pending_frames
fails, we either have too many packets in flight or our local device is
congested. In such cases its OK to not send.
Would like to know your comments.
Thanx,
tomar
-- You have moved the mouse. Windows must be restarted for the
changes to take effect.
-
: 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
