Re: PPP feature request (Tx queue len + close)

[Maksim Krasnyanskiy <maxk@qualcomm.com>]

> > You _will_ drop it, if txqueue is full. TCP will back off and re-transmit
> > but this will not allow TCP window to grow and you TCP performance will
> > be pretty bad.
>
>         Ok, I didn't look at the network code, so I have to take your
>word for it. I would have assumed that the logical thing would be to
>flow control within the network stack (like it's done in IrDA), but it
>seem that I was wrong.
I looked at the code again and tried to trace TCP xmit path. Seems like it 
should not
back off because it does check return status of the dev_queue_xmit (send 
packet to the driver).
But it does not seem to retry either. Looks like it's just waits for an ack 
from the other side which
effectively makes your window equal to 1 segment. In any case small PPP 
queue won't make any
good for you.

> > I totally agree with Paul. Just decrease buffering below PPP.
>
>         If what you say is true, I should *increase* the buffering
>below PPP to make sure that packet don't get dropped above PPP.
I was under assumption that you know for sure that buffering is bad for you :)

>         Think about it : for TCP, it doesn't matter if buffers are
>above or below PPP, what matter is only how many there are. TCP can't
>make the difference between buffers at the PPP and at IrDA level.
>         Actually, it's probably better to keep the buffers as low as
>possible in the stack, because less processing remain to be done on
>them before beeing transmitted.
All this depends on what you want to achieve. If you're looking for max TCP
performance. I'd recommend to use tcptrace and see what actually is going on.
May be your RTT is to high and you need bigger windows or may be there is
something else.

Max