prequeue still a good idea?

netdev

prequeue still a good idea?

To:	netdev@xxxxxxxxxxx
Subject:	prequeue still a good idea?
From:	Andrew Grover <andy.grover@xxxxxxxxx>
Date:	Thu, 28 Apr 2005 11:49:32 -0700
Domainkey-signature:	a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dSl3cXLo1fx2D4587po1/36mXfRBiSTxEs1Bw5arFYbG9BgfEWz+eONHtU9q4SWqryLr3pp8843jBYFu9KleEWXKtfanGX/aZ/76ZcnplnXqBzBvmwd8shYWms2GZsvUjmUA8pmkMnJhpSRjDpRS9hls6moWU6KDNcynkq8IeRo=
Reply-to:	Andrew Grover <andy.grover@xxxxxxxxx>
Sender:	netdev-bounce@xxxxxxxxxxx

I came across this comment from include/net/tcp.h tcp_prequeue:

/* Packet is added to VJ-style prequeue for processing in process
 * context, if a reader task is waiting. Apparently, this exciting
 * idea (VJ's mail "Re: query about TCP header on tcp-ip" of 07 Sep 93)
 * failed somewhere. Latency? Burstiness? Well, at least now we will
 * see, why it failed. 8)8)                               --ANK
 */

I'm trying to understand -- is the prequeue really not a win, and if
so, why do we still have it?

Especially with modern tcp csumming HW, its benefit is not clear to
me. The whole point of the prequeue, and calling tcp_v4_do_rcv from
user context, was to speed up *sw* csum, right?

Thanks -- Regards -- Andy

[More with this subject...]

<Prev in Thread]	Current Thread	[Next in Thread>
prequeue still a good idea?, Andrew Grover <= Re: prequeue still a good idea?, David S. Miller

Previous by Date:	RE: list admin? unsubscribing from the list?, Linda Xie
Next by Date:	Re: prequeue still a good idea?, David S. Miller
Previous by Thread:	Non-blocking sockets, connect(), and socket states, Bernard Blackham
Next by Thread:	Re: prequeue still a good idea?, David S. Miller
Indexes:	[Date] [Thread] [Top] [All Lists]