[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iK88gJG2PsEnXWmN=kPydVqbNGZeLQ69p+Ho+60FWzaSw@mail.gmail.com>
Date: Fri, 14 Jun 2024 10:25:01 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Paolo Abeni <pabeni@...hat.com>, Mike Maloney <maloney@...gle.com>,
Willem de Bruijn <willemb@...gle.com>
Cc: Philo Lu <lulie@...ux.alibaba.com>, netdev@...r.kernel.org, rostedt@...dmis.org,
mhiramat@...nel.org, mathieu.desnoyers@...icios.com, davem@...emloft.net,
dsahern@...nel.org, kuba@...nel.org, xuanzhuo@...ux.alibaba.com,
dust.li@...ux.alibaba.com, Soheil Hassas Yeganeh <soheil@...gle.com>
Subject: Re: [PATCH net-next] tcp: Add tracepoint for rxtstamp coalescing
On Fri, Jun 14, 2024 at 10:09 AM Paolo Abeni <pabeni@...hat.com> wrote:
>
> On Tue, 2024-06-11 at 12:58 +0800, Philo Lu wrote:
> > During tcp coalescence, rx timestamps of the former skb ("to" in
> > tcp_try_coalesce), will be lost. This may lead to inaccurate
> > timestamping results if skbs come out of order.
> >
> > Here is an example.
> > Assume a message consists of 3 skbs, namely A, B, and C. And these skbs
> > are processed by tcp in the following order:
> > A -(1us)-> C -(1ms)-> B
>
> IMHO the above order makes the changelog confusing
>
> > If C is coalesced to B, the final rx timestamps of the message will be
> > those of C. That is, the timestamps show that we received the message
> > when C came (including hardware and software). However, we actually
> > received it 1ms later (when B came).
> >
> > With the added tracepoint, we can recognize such cases and report them
> > if we want.
>
> We really need very good reasons to add new tracepoints to TCP. I'm
> unsure if the above example match such requirement. The reported
> timestamp actually matches the first byte in the aggregate segment,
> inferring anything more is IMHO stretching too far the API semantic.
>
Note the current behavior was a conscious choice, see
commit 98aaa913b4ed2503244 ("tcp: Extend SOF_TIMESTAMPING_RX_SOFTWARE
to TCP recvmsg")
for the rationale.
Perhaps another application would need to add a new timestamp to report
both the oldest and newest timestamps.
Or add a socket flag to prevent coalescing for applications needing
precise timestamps.
Willem might know better about this.
I agree the tracepoint seems not needed. What about solving the issue instead ?
Powered by blists - more mailing lists