Re: [PATCH net 2/2] tcp: fix delayed ACKs for MSS boundary condition

[Xin Guo <guoxin0309@gmail.com>]

Neal,
thanks for your explanation,
1)when I read the patch, i cannot understood "if an app reads  >1*MSS data",
because in my view that "the app reads" mean that the copied data
length from sk_receive_queue to user-space buffer
in function tcp_recvmsg_locked(as example) when an app reads data from a socket,
but for "tp->rcv_nxt - tp->rcv_wup > icsk->icsk_ack.rcv_mss ||"
"tp->rcv_nxt - tp->rcv_wup" means that the received data length from
last ack in the kernel for the sk,
and not always the length of copied data to user-space buffer.

2) when we received two small packets(<1*MSS) in the kernel for the
sk, the total length of the two packets may  > 1*MSS.

Regards
Guo Xin

Neal Cardwell <ncardwell@google.com> 于2023年9月28日周四 22:38写道：
>
> On Thu, Sep 28, 2023, 4:53 AM Xin Guo <guoxin0309@gmail.com> wrote:
> >
> > Hi Neal:
> > Cannot understand "if an app reads > 1*MSS data" , " If an app reads <
> > 1*MSS data" and " if an app reads exactly 1*MSS of data" in the commit
> > message.
> > In my view, it should be like:"if an app reads and received data > 1*MSS",
> > " If an app reads and received data < 1*MSS" and " if an app reads and
> > received data exactly 1*MSS".
>
> AFAICT your suggestion for tweaking the commit message - "if an app
> reads and received" - would be redundant.  Our proposed phrase, "if an
> app reads", is sufficient, because a read of a certain amount of data
> automatically implies that the data has been received. That is, the
> "and received" part is implied already. After all, how would an app
> read data if it has not been received? :-)
>
> best regards,
> neal