[PATCH] Add more explanation to tcp_prequeue comment

[PATCH] Add more explanation to tcp_prequeue comment

[Andrew Grover]

Here's a patch to make that prequeue comment a little clearer. Look ok?

Signed-off-by: Andy Grover <andrew.grover@intel.com>

===== include/net/tcp.h 1.105 vs edited =====
--- 1.105/include/net/tcp.h     2005-02-22 10:45:31 -08:00
+++ edited/include/net/tcp.h    2005-04-28 14:02:43 -07:00
@@ -1560,6 +1560,13 @@
  * 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
+ *
+ * Actually, even though the prequeue is not as important for fast
+ * csum anymore, it is important for scheduling, to generate ACKs
+ * when the data is received by the process, not the stack.
+ * davem says, "Without prequeue, we ACK immediately. This artificially
+ * makes the sender believe it can pump data out at that rate to the
+ * receiver."
  *
  * NOTE: is this not too big to inline?
  */

Re: [PATCH] Add more explanation to tcp_prequeue comment

[Arnaldo Carvalho de Melo]

On 4/28/05, Andrew Grover <andy.grover@gmail.com> wrote:
> Here's a patch to make that prequeue comment a little clearer. Look ok?
> 
> Signed-off-by: Andy Grover <andrew.grover@intel.com>
> 
> ===== include/net/tcp.h 1.105 vs edited =====
> --- 1.105/include/net/tcp.h     2005-02-22 10:45:31 -08:00
> +++ edited/include/net/tcp.h    2005-04-28 14:02:43 -07:00
> @@ -1560,6 +1560,13 @@
>   * 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
> + *
> + * Actually, even though the prequeue is not as important for fast
> + * csum anymore, it is important for scheduling, to generate ACKs
> + * when the data is received by the process, not the stack.
> + * davem says, "Without prequeue, we ACK immediately. This artificially
> + * makes the sender believe it can pump data out at that rate to the
> + * receiver."

Cool, great comment, for me the funny thing is that this is one of the
differences
of DCCP x TCP, i.e. in DCCP we must ack it _before_ it gets to sk_receive_queue,
if later on we drop the packet for any reason we send DATA_DROPPED
options to the sender.

from draft-ietf-dccp-spec-11.txt:

    1.  Packets reported as State 0 or State 1 MUST be acknowledgeable:
        their options have been processed by the receiving DCCP stack.
        Any data on the packet need not have been delivered to the
        receiving application; in fact, the data may have been dropped.

    Packets dropped in the application's receive buffer MUST be reported
    as Received or Received ECN Marked (States 0 and 1), depending on
    their ECN state; such packets' ECN Nonces MUST be included in the
    Nonce Echo.  The Data Dropped option informs the sender that some
    packets reported as received actually had their application data
    dropped.

- Arnaldo

Re: [PATCH] Add more explanation to tcp_prequeue comment

[David S. Miller]

On Thu, 28 Apr 2005 14:14:13 -0700
Andrew Grover <andy.grover@gmail.com> wrote:

> Here's a patch to make that prequeue comment a little clearer. Look ok?

Looks great, except that it does not apply cleanly.