On Mon, Aug 07, 2006 at 02:00:24PM -0400, jamal wrote:
> On Mon, 2006-07-08 at 19:04 +0200, Edgar E. Iglesias wrote:
>
> >
> > I'll give you an example.
>
> Thanks - that matches my understanding.
>
> > 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?
> >
>
> I am hoping they will be freed by a tx interrupt that will force poll to
> happen. Or a new packet arrival etc. Just like before. Why do you see
> the two as different? (the tx path pruning is still going on as i noted
> before). If all you are looking for is a scheme to quickly free the skbs
> so that TCP doesnt get charged, I am not sure if this is the right one.
>
I think we are out of sync :) My, fault I haven't been clear enough.
First of all, I don't think the patch with jamal undefined has any problems. I
assumed wrongly from the start that you somehow wanted that part to go in
aswell, sorry about that. As you say, the flow goes just as before.
Now, with jamal defined, I only see e1000_prune_tx_ring beeing called if
fdesc < tx_ring->prunet or fdesc < tx_ring->waket. In other words, the freing
of skbs is dependant on external events that might not become true if the
host is quiet. Skb's could end up sitting on the ring indefinitely.
Sorry for the confusion.
--
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
