Messages in this thread | | | Date | Mon, 28 Feb 2011 23:11:13 -0500 | Subject | Re: txqueuelen has wrong units; should be time | From | Albert Cahalan <> |
| |
On Mon, Feb 28, 2011 at 4:45 PM, John Heffner <johnwheffner@gmail.com> wrote: > On Mon, Feb 28, 2011 at 11:55 AM, John W. Linville > <linville@tuxdriver.com> wrote: >> On Mon, Feb 28, 2011 at 05:48:14PM +0100, Eric Dumazet wrote: >>> Le lundi 28 février 2011 à 11:11 -0500, John W. Linville a écrit : >>> > On Sun, Feb 27, 2011 at 09:07:53PM +0100, Eric Dumazet wrote:
>>> > > Qdisc should return to caller a good indication packet is queued or >>> > > dropped at enqueue() time... not later (aka : never) >>> > > >>> > > Accepting a packet at t0, and dropping it later at t0+limit without >>> > > giving any indication to caller is a problem. >>> > >>> > Can you elaborate on what problem this causes? Is it any worse than >>> > if the packet is dropped at some later hop? >>> > >>> > Is there any API that could report the drop to the sender (at >>> > least a local one) without having to wait for the ack timeout? >>> > Should there be? >>> >>> Not all protocols have ACKS ;) >>> >>> dev_queue_xmit() returns an error code, some callers use it. >> >> Well, OK -- I agree it is best if you can return the status at >> enqueue time. The question becomes whether or not a dropped frame >> is worse than living with high latency. The answer, of course, still >> seems to be a bit subjective. But, if the admin has determined that >> a link should be low latency...? > > Notably, TCP is one caller that uses the error code. The error code > is functionally equivalent to ECN, one of whose great advantages is > reducing delay jitter. If TCP didn't get the error, that would > effectively double the latency for a full window of data, since the > dropped segment would not be retransmitted for an RTT.
It sounds like you need a callback or similar, so that TCP can be informed later that the drop has occurred. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |