From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Fred Klassen <fklassen@appneta.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Shuah Khan <shuah@kernel.org>,
Network Development <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-kselftest@vger.kernel.org,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO
Date: Fri, 24 May 2019 00:53:37 -0400 [thread overview]
Message-ID: <CAF=yD-LtAKpND601LQrC1+=iF6spSUXVdUapcsbJdv5FYa=5Jg@mail.gmail.com> (raw)
In-Reply-To: <AE8E0772-7256-4B9C-A990-96930E834AEE@appneta.com>
On Thu, May 23, 2019 at 9:38 PM Fred Klassen <fklassen@appneta.com> wrote:
>
> > Thanks for the report.
> >
> > Zerocopy notification reference count is managed in skb_segment. That
> > should work.
> >
> > Support for timestamping with the new GSO feature is indeed an
> > oversight. The solution is similar to how TCP associates the timestamp
> > with the right segment in tcp_gso_tstamp.
> >
> > Only, I think we want to transfer the timestamp request to the last
> > datagram, not the first. For send timestamp, the final byte leaving
> > the host is usually more interesting.
>
> TX Timestamping the last packet of a datagram is something that would
> work poorly for our application. We need to measure the time it takes
> for the first bit that is sent until the first bit of the last packet is received.
> Timestaming the last packet of a burst seems somewhat random to me
> and would not be useful. Essentially we would be timestamping a
> random byte in a UDP GSO buffer.
>
> I believe there is a precedence for timestamping the first packet. With
> IPv4 packets, the first packet is timestamped and the remaining fragments
> are not.
Interesting. TCP timestamping takes the opposite choice and does
timestamp the last byte in the sendmsg request.
It sounds like it depends on the workload. Perhaps this then needs to
be configurable with an SOF_.. flag.
Another option would be to return a timestamp for every segment. But
they would all return the same tskey. And it causes different behavior
with and without hardware offload.
next prev parent reply other threads:[~2019-05-24 4:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 21:06 [PATCH net 0/4] Allow TX timestamp with UDP GSO Fred Klassen
2019-05-23 21:06 ` [PATCH net 1/4] net/udp_gso: " Fred Klassen
2019-05-23 21:39 ` Willem de Bruijn
2019-05-24 1:38 ` Fred Klassen
2019-05-24 4:53 ` Willem de Bruijn [this message]
2019-05-24 16:34 ` Fred Klassen
2019-05-24 19:29 ` Willem de Bruijn
2019-05-24 22:01 ` Fred Klassen
2019-05-25 15:20 ` Willem de Bruijn
2019-05-25 18:47 ` Fred Klassen
2019-05-27 1:30 ` Willem de Bruijn
2019-05-27 2:09 ` Willem de Bruijn
2019-05-25 20:46 ` Fred Klassen
2019-05-23 21:59 ` Willem de Bruijn
2019-05-25 20:09 ` Fred Klassen
2019-05-25 20:47 ` Fred Klassen
2019-05-23 21:06 ` [PATCH net 2/4] net/udpgso_bench_tx: options to exercise TX CMSG Fred Klassen
2019-05-23 21:45 ` Willem de Bruijn
2019-05-23 21:52 ` Willem de Bruijn
2019-05-24 2:10 ` Fred Klassen
2019-05-23 21:06 ` [PATCH net 3/4] net/udpgso_bench_tx: fix sendmmsg on unconnected socket Fred Klassen
2019-05-23 21:06 ` [PATCH net 4/4] net/udpgso_bench_tx: audit error queue Fred Klassen
2019-05-23 21:56 ` Willem de Bruijn
2019-05-24 1:27 ` Fred Klassen
2019-05-24 5:02 ` Willem de Bruijn
2019-05-27 21:30 ` Fred Klassen
2019-05-27 21:46 ` Willem de Bruijn
2019-05-27 22:56 ` Fred Klassen
2019-05-28 1:15 ` Willem de Bruijn
2019-05-28 5:19 ` Fred Klassen
2019-05-28 15:08 ` Willem de Bruijn
2019-05-28 16:57 ` Fred Klassen
2019-05-28 17:07 ` Willem de Bruijn
2019-05-28 17:11 ` Willem de Bruijn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAF=yD-LtAKpND601LQrC1+=iF6spSUXVdUapcsbJdv5FYa=5Jg@mail.gmail.com' \
--to=willemdebruijn.kernel@gmail.com \
--cc=davem@davemloft.net \
--cc=fklassen@appneta.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=willemb@google.com \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).