Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp3472000pxy; Mon, 26 Apr 2021 02:34:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUtSExJIZYIKghpoQD8D8WTkl2PxOkJ+shDZqUWXQQdO2Cg3RyUReAsKuA2vUDxZk+M9Ka X-Received: by 2002:aa7:cb4b:: with SMTP id w11mr19935201edt.216.1619429650937; Mon, 26 Apr 2021 02:34:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619429650; cv=none; d=google.com; s=arc-20160816; b=cuwuXWPcg/JRy2hfdkq0BLE7UqPaz44uzqU7S3xo4i77tY+9+36vdirRvjgh8LY7wu zKvoIkyJTe2fnxfx7ZhwfmdTOUux9mnFCs5PXgN0k7JsD8RW7ce6ncxVFBADLpg/uMj0 MLQ1MVYgG83ZsnGIsezzkUMr49nBRK/pRczad9zTSIA97QySFs9QPBUbvoUIzeZJ5pKW DZNY/mI6Ei54VCME+F1FKgrcs1JR8k4DiJNu+wM356teLP0ud3H+h03oGmh3+/MqrrDE HphCWnhg2biesBOdLJ6zM6wtJ2N40vTaEa1sIhThEH/+PPwIojSBkkJFtLrs3lwgGeTc wkhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from; bh=hxsGHbk8mwYLbzq7zf/jOzYg+Fp9PhX4zDNtsqyRmW4=; b=Dv2o1aj08NS48hw+YwaF1yTryObIRPksR9qKIWZGpTbjqMJfrohKthN8jUBDCmUjLi 4wmDzLlV3KHfhHY7Cjyr5Z8IzfqZcpitqwTMqOEIjRAAZe/JIUxin2PwRz2O+Jmet8jW +P/6FAjR+pWXyFMo6cvp27OwMFKD22BQ0+SgqZ8L5K6BiG81z8vdRtI+hfjpGGNM7+hA ir2QyCFuNJHkvq4nSew+gp5+mDAYE3YFC2c0HgHfBo+sHinIL1AZiUFcF4za6dH7du2C yfuoXhohIO0hmo+qHEtMF6SSQRZb/1y8ZmA3e048uuyi9PYUHEk4HJBg0GszEHdTVmpC aLXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ss2si13247151ejb.370.2021.04.26.02.33.47; Mon, 26 Apr 2021 02:34:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=nxp.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232733AbhDZJdJ (ORCPT + 99 others); Mon, 26 Apr 2021 05:33:09 -0400 Received: from inva020.nxp.com ([92.121.34.13]:42628 "EHLO inva020.nxp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232601AbhDZJc7 (ORCPT ); Mon, 26 Apr 2021 05:32:59 -0400 Received: from inva020.nxp.com (localhost [127.0.0.1]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id 1078D1A3506; Mon, 26 Apr 2021 11:32:13 +0200 (CEST) Received: from invc005.ap-rdc01.nxp.com (invc005.ap-rdc01.nxp.com [165.114.16.14]) by inva020.eu-rdc02.nxp.com (Postfix) with ESMTP id C575C1A34E0; Mon, 26 Apr 2021 11:32:06 +0200 (CEST) Received: from localhost.localdomain (mega.ap.freescale.net [10.192.208.232]) by invc005.ap-rdc01.nxp.com (Postfix) with ESMTP id DB758402DA; Mon, 26 Apr 2021 11:31:58 +0200 (CEST) From: Yangbo Lu To: netdev@vger.kernel.org Cc: Yangbo Lu , Richard Cochran , Vladimir Oltean , "David S . Miller" , Jakub Kicinski , Jonathan Corbet , Kurt Kanzenbach , Andrew Lunn , Vivien Didelot , Florian Fainelli , Claudiu Manoil , Alexandre Belloni , UNGLinuxDriver@microchip.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [net-next, v2, 5/7] docs: networking: timestamping: update for DSA switches Date: Mon, 26 Apr 2021 17:38:00 +0800 Message-Id: <20210426093802.38652-6-yangbo.lu@nxp.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210426093802.38652-1-yangbo.lu@nxp.com> References: <20210426093802.38652-1-yangbo.lu@nxp.com> X-Virus-Scanned: ClamAV using ClamSMTP Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Update timestamping doc for DSA switches to describe current implementation accurately. On TX, the skb cloning is no longer in DSA generic code. Signed-off-by: Yangbo Lu --- Changes for v2: - Split from tx timestamp optimization big patch. - Updated the doc. --- Documentation/networking/timestamping.rst | 63 ++++++++++++++--------- 1 file changed, 39 insertions(+), 24 deletions(-) diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index f682e88fa87e..7db3985359bc 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -630,30 +630,45 @@ hardware timestamping on it. This is because the SO_TIMESTAMPING API does not allow the delivery of multiple hardware timestamps for the same packet, so anybody else except for the DSA switch port must be prevented from doing so. -In code, DSA provides for most of the infrastructure for timestamping already, -in generic code: a BPF classifier (``ptp_classify_raw``) is used to identify -PTP event messages (any other packets, including PTP general messages, are not -timestamped), and provides two hooks to drivers: - -- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb - to be transmitted, before actually transmitting it. Typically, a switch will - have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp - becomes available. There may be an IRQ that is raised upon this timestamp's - availability, or the driver might have to poll after invoking - ``dev_queue_xmit()`` towards the host interface. Either way, in the - ``.port_txtstamp()`` method, the driver only needs to save the clone for - later use (when the timestamp becomes available). Each skb is annotated with - a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's - job of keeping track of which clone belongs to which skb. - -- ``.port_rxtstamp()``: The original (and only) timestampable skb is provided - to the driver, for it to annotate it with a timestamp, if that is immediately - available, or defer to later. On reception, timestamps might either be - available in-band (through metadata in the DSA header, or attached in other - ways to the packet), or out-of-band (through another RX timestamping FIFO). - Deferral on RX is typically necessary when retrieving the timestamp needs a - sleepable context. In that case, it is the responsibility of the DSA driver - to call ``netif_rx_ni()`` on the freshly timestamped skb. +In the generic layer, DSA provides the following infrastructure for PTP +timestamping: + +- ``.port_txtstamp()``: a hook called prior to the transmission of + packets with a hardware TX timestamping request from user space. + This is required for two-step timestamping, since the hardware + timestamp becomes available after the actual MAC transmission, so the + driver must be prepared to correlate the timestamp with the original + packet so that it can re-enqueue the packet back into the socket's + error queue. To save the packet for when the timestamp becomes + available, the driver can call ``skb_clone_sk`` , save the clone pointer + in skb->cb and enqueue a tx skb queue. Typically, a switch will have a + PTP TX timestamp register (or sometimes a FIFO) where the timestamp + becomes available. In case of a FIFO, the hardware might store + key-value pairs of PTP sequence ID/message type/domain number and the + actual timestamp. To perform the correlation correctly between the + packets in a queue waiting for timestamping and the actual timestamps, + drivers can use a BPF classifier (``ptp_classify_raw``) to identify + the PTP transport type, and ``ptp_parse_header`` to interpret the PTP + header fields. There may be an IRQ that is raised upon this + timestamp's availability, or the driver might have to poll after + invoking ``dev_queue_xmit()`` towards the host interface. + One-step TX timestamping do not require packet cloning, since there is + no follow-up message required by the PTP protocol (because the + TX timestamp is embedded into the packet by the MAC), and therefore + user space does not expect the packet annotated with the TX timestamp + to be re-enqueued into its socket's error queue. + +- ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to + identify PTP event messages (any other packets, including PTP general + messages, are not timestamped). The original (and only) timestampable + skb is provided to the driver, for it to annotate it with a timestamp, + if that is immediately available, or defer to later. On reception, + timestamps might either be available in-band (through metadata in the + DSA header, or attached in other ways to the packet), or out-of-band + (through another RX timestamping FIFO). Deferral on RX is typically + necessary when retrieving the timestamp needs a sleepable context. In + that case, it is the responsibility of the DSA driver to call + ``netif_rx_ni()`` on the freshly timestamped skb. 3.2.2 Ethernet PHYs ^^^^^^^^^^^^^^^^^^^ -- 2.25.1