Date: Thu, 20 Jan 2000 15:58:16 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Dave: Side item tcp_retrans_try_collapse doesnt seem to care about collapsing
in SACK'd data - is that right ?
It refuses to coalesce SACK'd packets, as per the test:
/* Also punt if next skb has been SACK'd. */
if(TCP_SKB_CB(next_skb)->sacked & TCPCB_SACKED_ACKED)
return;
skb->next being NULL is an illegal state for the write_queue,
the queue is a ring list, so the tail element must point to
the beginning of the write_queue.
Second question: tcp_xmit_retransmit_queue is entered with
tcp->retrans_head pointing part way into the retransmit queue if we
baled part way through the previous retransmit run (eg cos cwnd got
us). We guarantees that tp->retrans_head is still pointing to a
valid packet so right now I cant see a cause.
Correct. There are several checks for NULL, anything which
fixes it up points it at the head of the write_queue which
by definition is not empty.
All of this code is protected by asynchronous behavior either
by virtue of running in BH or from the user within' BH atomic
backlog processing.
As in many cases, we still have the ugly "kfree_skb() runs
destructor in hardware IRQ context" stuff which can mess
with socket state. I've been over these paths several
times and they absoultely cannot mess with the socket
write queue, or retrans_head/send_head in any way.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:24 EST