From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02287C282E1 for ; Fri, 24 May 2019 22:01:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C5FEC217F9 for ; Fri, 24 May 2019 22:01:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=appneta.com header.i=@appneta.com header.b="CP3pG9if" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404444AbfEXWB1 (ORCPT ); Fri, 24 May 2019 18:01:27 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:42712 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404303AbfEXWB0 (ORCPT ); Fri, 24 May 2019 18:01:26 -0400 Received: by mail-pf1-f194.google.com with SMTP id r22so3200689pfh.9 for ; Fri, 24 May 2019 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appneta.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nt1Bto+RuKAe8F0XKPOQ+MhI4MGCp3IBcqE1bNWm624=; b=CP3pG9ifqRjFBc0YzSgRZhosVC3X/Gn1RGmFGqOzuMcKIczmIs/OCyyjYxWltNsfFk 4mycd8lZIITJoEB+fcpjf8FT1kv+xkBDmO6lK+fhB4wuUjsW2BKF02fS2SVSabb57vwh ANBUCNIjYnb5tPURfcu15IQNfhbH/7OJVk0es= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Nt1Bto+RuKAe8F0XKPOQ+MhI4MGCp3IBcqE1bNWm624=; b=IES4m+iRROqFO44l+g530S8/TaeB8i4F8Nc3xVm4l6QwQj3iu54ehy/Cg023KBQxCP 2v/iRIdmhGk5L4vHULB3THSDagHQlQsa3a6BRjDy1WjXktnL3ItwgqVIksRPTU4ErjvE /VEGfLZJ/F0DRh9wcOlCP//4VpLiWcrX+9JjR/SL8ZLQ9i08kHRVjaI95w4y3ng1b5S0 p6Vq3pAHIHBN3DwImg2CzcpqBpWsTibD/bNhpHXhHTKFrjHItbvWtpiON7JAMzV8LOJz kG7FA81eRN1Y8WqmDmziHphY7pZzZAKcLrCyh54C7ARsKm3SZeDOEm9fRVhQcF/Wvmeq Fqbg== X-Gm-Message-State: APjAAAU2FAwQwFyIiihAw3zu+4cy8/c30uFtO6cuhPER676KbowxDHbQ +MtTGVebG3G4j3hRrwE6uYvGsA== X-Google-Smtp-Source: APXvYqx1AU7WlE+4JCn2Y/DvThwLZLnoOhh2EBVLKjNWpqmzprHergerEz/Wt2MlbcL6sAcU78Bqng== X-Received: by 2002:a17:90a:216d:: with SMTP id a100mr12026144pje.6.1558735285565; Fri, 24 May 2019 15:01:25 -0700 (PDT) Received: from jltm109.jaalam.net (vancouver-a.appneta.com. [209.139.228.33]) by smtp.gmail.com with ESMTPSA id e123sm3645702pgc.29.2019.05.24.15.01.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 15:01:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: [PATCH net 1/4] net/udp_gso: Allow TX timestamp with UDP GSO From: Fred Klassen In-Reply-To: Date: Fri, 24 May 2019 15:01:24 -0700 Cc: "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , Shuah Khan , Network Development , LKML , linux-kselftest@vger.kernel.org, Willem de Bruijn Content-Transfer-Encoding: quoted-printable Message-Id: <90E3853F-107D-45BA-93DC-D0BE8AC6FCBB@appneta.com> References: <20190523210651.80902-1-fklassen@appneta.com> <20190523210651.80902-2-fklassen@appneta.com> To: Willem de Bruijn X-Mailer: Apple Mail (2.3445.104.8) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 24, 2019, at 12:29 PM, Willem de Bruijn = wrote: >=20 > It is the last moment that a timestamp can be generated for the last > byte, I don't see how that is "neither the start nor the end of a GSO > packet=E2=80=9D. My misunderstanding. I thought TCP did last segment timestamping, not last byte. In that case, your statements make sense. >> It would be interesting if a practical case can be made for = timestamping >> the last segment. In my mind, I don=E2=80=99t see how that would be = valuable. >=20 > It depends whether you are interested in measuring network latency or > host transmit path latency. >=20 > For the latter, knowing the time from the start of the sendmsg call to > the moment the last byte hits the wire is most relevant. Or in absence > of (well defined) hardware support, the last byte being queued to the > device is the next best thing. >=20 > It would make sense for this software implementation to follow > established hardware behavior. But as far as I know, the exact time a > hardware timestamp is taken is not consistent across devices, either. >=20 > For fine grained timestamped data, perhaps GSO is simply not a good > mechanism. That said, it still has to queue a timestamp if requested. I see your point. Makes sense to me. >> When using hardware timestamping, I think you will find that nearly = all >> adapters only allow one timestamp at a time. Therefore only one >> packet in a burst would get timestamped. >=20 > Can you elaborate? When the host queues N packets all with hardware > timestamps requested, all N completions will have a timestamp? Or is > that not guaranteed? >=20 It is not guaranteed. The best example is in ixgbe_main.c and search for =E2=80=98SKBTX_HW_TSTAMP=E2=80=99. If there is a PTP TX timestamp in = progress, =E2=80=98__IXGBE_PTP_TX_IN_PROGRESS=E2=80=99 is set and no other = timestamps are possible. The flag is cleared after transmit softirq, and only then can another TX timestamp be taken. =20 >> There are exceptions, for >> example I am playing with a 100G Mellanox adapter that has >> per-packet TX timestamping. However, I suspect that when I am >> done testing, all I will see is timestamps that are representing wire >> rate (e.g. 123nsec per 1500 byte packet). >>=20 >> Beyond testing the accuracy of a NIC=E2=80=99s timestamping = capabilities, I >> see very little value in doing per-segment timestamping. >=20 > Ack. Great detailed argument, thanks. Thanks. I=E2=80=99m a timestamping nerd and have learned lots with this=20= discussion.