On Mon, Aug 07, 2006 at 12:31:59PM -0400, Jamal Hadi Salim wrote:
> On Mon, 2006-07-08 at 17:59 +0200, Edgar E. Iglesias wrote:
>
> > Ok, I thought you wanted the code inside the ifdefs to be considered. If
> > not,
> > I guess there is no problem. Yes, the forwarding case does not suffer from
> > any deadlocks issues that I am aware of.
> >
>
> >From my tests:
> It does _not_ provide any performance improvements and at some point i decided
> i didnt want to add more variables to analyze, so i got rid of it; I would
> have
> had to hand edit the patch to totally remove it; so that why you still see
> the
> ifdefed out variant.
>
> > No, the deadlock happens only if you don't prune the descriptors. If the
> > host
> > sends some data and then goes quite, fdesc < tx_ring->prunet might not be
> > true for a long time and skbs will end up sitting in the tx ring
> > indefinitely,
> > charging the socket's sndbuf.
> >
>
> Note: I didnt get rid of the rx path pruning. i.e that is still on. It
> just prunes lesser descriptors with that change on the tx. So not very
> different from before.
>
> I think i may be getting a gist now of the discussion after a re-read;
> while packets are still charged to TCP may have been transmitted they may sit
> on the tx ring forever. They will only be pruned if we had netif_stopped
> (and even that is not good enough with Jesse's threshold check) or if a
> new packet comes in destined for us.
> Did i understand correctly? If yes, i didnt introduce this challenge it
> has always been there. I think i understand the suggestion now from
> Dave/Herbert to orphan those skbs...
I'll give you an example.
A TCP flow sends X data and later waits for a response, host is now quietly
waiting. Assume fdesc >= tx_ring->prunet, so we dont free any skbs, right?
Now assume that some part of X data gets lost, our retransmit timer hits and
we want to retransmit but our socket is charged with too much data sitting on
the nics tx-ring, so we don't send anything. By orphaning, those skbs won't
charge the socket and the flow can retransmit.
Best regards
--
Programmer
Edgar E. Iglesias <[EMAIL PROTECTED]> 46.46.272.1946
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
