On Thu, 18 Jan 2001, Andi Kleen wrote:
> On Thu, Jan 18, 2001 at 01:35:33AM +0100, mukesh agrawal wrote:
> > 2. If this can happen, is it worth changing? In particular, we might not
> > want to wait the entire RTT before retransmitting the packet if it was
> > dropped inside the kernel.
>
> 2.4 has most of the infrastructure neededfor that: TCP gets an error code now
> when the device queue overflows. It currently doesn't send more aggressively
> when this happens, but just doesn't advance snd_nxt, making established behave
> a bit better.
>
> I guess you could experiment with more aggressive reactions, especially
> for initial SYNs (no handling of this case there currently)
>
sorry, I totaly took his question out of context in my response by talking
about the receive path (it's that netlink thing!);-<
Your suggestion sounds good and the code change is trivial,
(tcp_transmit_skb() already returns NET_XMIT_CN in these situations).
I'd be interested in seeing the backoff algorithm though. The packets
might be getting dropped because of a lot of factors: some other socket
hogging resources, interupt livelock, slow devices, bandwidth control
etc. I wonder if you have to adapt different things in a slightly
different manner. I also wonder whether not advancing snd_nxt is a good
enough solution.
cheers,
jamal
|