On 4/28/05, Andrew Grover <andy.grover@xxxxxxxxx> wrote:
> Here's a patch to make that prequeue comment a little clearer. Look ok?
>
> Signed-off-by: Andy Grover <andrew.grover@xxxxxxxxx>
>
> ===== 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
|