From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by mail.toke.dk (Postfix) with ESMTPS id BBDC9A588C1 for ; Fri, 1 Mar 2024 18:54:39 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=f0wQwvw/ Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1dc1ff697f9so21969205ad.0 for ; Fri, 01 Mar 2024 09:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709315677; x=1709920477; darn=xdp-project.net; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=nTu8BntRycqg7yt21AHZn8UXSjkjplk0BJ11/qY4XBE=; b=f0wQwvw/7IsSbv17/lTddpLcrdXKkTV6YARUZAu6DZceSTZ7Del0DKJmpH2PK3wd6g zF+LgbQpD2xLZnAJqUmpS7+mbgKPhluKMutunP9Rn3QjCE85GGLbn6ZROdor0ZuJ6QCu 3VpfogSxWKTd+0mNfxvzNcaXouBVcZBSpD/TBkclm5+V+mCt22tZyglCpmNHTpnnhGaC XMxQZ/Q8Z7NUPCYqn1XEH/fEXSzfFxdOIsreobh0ffYqgPX5qoE8CAXio9FAjTmFAIlJ CyIdtgrIHEnaP0d72ISENMbkNG6u99rVl/6bcMLOCEx5yoXKzqmEeGAOcu9N7beWi8EC evKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709315677; x=1709920477; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=nTu8BntRycqg7yt21AHZn8UXSjkjplk0BJ11/qY4XBE=; b=OP3u3ctdhpsEHxdoG9AJ9Bx20bOUWRRI+OfApwIFr+wbKuhCKr5y5IPLB725Jhn5WQ mRzc3ck2JgzOc/e9V1hfieXc9Pp81yW5qU6zzMGO6h2PIskn0mqOyZNBHmptGDIew0u7 rGePs14KqflGX3Jlv+Z3xMu+wUQIMfrDyZ+aMXyFRsv1G+koHdlBzevTJaPUkpCq7dFt izXGB3sTa1/2aUQvEHH6AVIYpi1N7aGJdTneV9V0+w4KmHdwQg8ifT4k4TVAdxSMDsZF TQi2YdwqwOoDUyiCjLEO8tw3Pqh10GGkoNsgXk43NvcCeRWlvAt7v615Q3sy0HyDwSRZ qnGQ== X-Forwarded-Encrypted: i=1; AJvYcCUYN/jifTVtvUtaZo3J3aB1isx+/YBeZRjkpumEKgfDXBAe2ik7T0Nkok5dsigwuG0aYJcnw5Tj1BSKPUglxiORH70DN/F16jU7 X-Gm-Message-State: AOJu0YyLcVLLXSCxi59sFMXV0/fT325PRv3nMHVsLhZADfU45fVl/KqU ReFqXUQTzeu0m19jm41Q512wXOx7rDzeuT7MlumFyPoYNY5CJ623 X-Google-Smtp-Source: AGHT+IE9csmqmhCHH7CB4+0CxfUKKrr/8xABmiG0iw4SYFgI5JFB+8TUoh0+dZcVBRLvK/L83PLtYQ== X-Received: by 2002:a17:903:8c6:b0:1dc:d515:79ca with SMTP id lk6-20020a17090308c600b001dcd51579camr2747683plb.5.1709315676554; Fri, 01 Mar 2024 09:54:36 -0800 (PST) Received: from localhost ([98.97.43.160]) by smtp.gmail.com with ESMTPSA id e8-20020a170902784800b001da001aed18sm3800862pln.54.2024.03.01.09.54.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 09:54:35 -0800 (PST) Date: Fri, 01 Mar 2024 09:54:34 -0800 From: John Fastabend To: Song Yoong Siang , Jesse Brandeburg , Tony Nguyen , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Vinicius Costa Gomes , Florian Bezdeka , Andrii Nakryiko , Eduard Zingerman , Mykola Lysenko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan Message-ID: <65e2165a89ed0_5dcfe20823@john.notmuch> In-Reply-To: <20240301162348.898619-3-yoong.siang.song@intel.com> References: <20240301162348.898619-1-yoong.siang.song@intel.com> <20240301162348.898619-3-yoong.siang.song@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Message-ID-Hash: 32CHIULHJEHVLTBE3DLVOIBSVSUBRIRG X-Message-ID-Hash: 32CHIULHJEHVLTBE3DLVOIBSVSUBRIRG X-MailFrom: john.fastabend@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, xdp-hints@xdp-project.net X-Mailman-Version: 3.3.9 Precedence: list Subject: [xdp-hints] Re: [PATCH iwl-next,v2 2/2] igc: Add Tx hardware timestamp request for AF_XDP zero-copy packet List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Song Yoong Siang wrote: > This patch adds support to per-packet Tx hardware timestamp request to > AF_XDP zero-copy packet via XDP Tx metadata framework. Please note that > user needs to enable Tx HW timestamp capability via igc_ioctl() with > SIOCSHWTSTAMP cmd before sending xsk Tx hardware timestamp request. > > Same as implementation in RX timestamp XDP hints kfunc metadata, Timer 0 > (adjustable clock) is used in xsk Tx hardware timestamp. i225/i226 have > four sets of timestamping registers. Both *skb and *xsk_tx_buffer pointers > are used to indicate whether the timestamping register is already occupied. > > Furthermore, a boolean variable named xsk_pending_ts is used to hold the > transmit completion until the tx hardware timestamp is ready. This is > because, for i225/i226, the timestamp notification event comes some time > after the transmit completion event. The driver will retrigger hardware irq > to clean the packet after retrieve the tx hardware timestamp. > > Besides, xsk_meta is added into struct igc_tx_timestamp_request as a hook > to the metadata location of the transmit packet. When the Tx timestamp > interrupt is fired, the interrupt handler will copy the value of Tx hwts > into metadata location via xsk_tx_metadata_complete(). > > Co-developed-by: Lai Peter Jun Ann > Signed-off-by: Lai Peter Jun Ann > Signed-off-by: Song Yoong Siang > --- [...] > > +static void igc_xsk_request_timestamp(void *_priv) > +{ > + struct igc_metadata_request *meta_req = _priv; > + struct igc_ring *tx_ring = meta_req->tx_ring; > + struct igc_tx_timestamp_request *tstamp; > + u32 tx_flags = IGC_TX_FLAGS_TSTAMP; > + struct igc_adapter *adapter; > + unsigned long lock_flags; > + bool found = false; > + int i; > + > + if (test_bit(IGC_RING_FLAG_TX_HWTSTAMP, &tx_ring->flags)) { > + adapter = netdev_priv(tx_ring->netdev); > + > + spin_lock_irqsave(&adapter->ptp_tx_lock, lock_flags); > + > + /* Search for available tstamp regs */ > + for (i = 0; i < IGC_MAX_TX_TSTAMP_REGS; i++) { > + tstamp = &adapter->tx_tstamp[i]; > + > + if (tstamp->skb) > + continue; > + > + found = true; > + break; Not how I would have written this loop construct seems a bit odd to default break but it works. > + } > + > + /* Return if no available tstamp regs */ > + if (!found) { > + adapter->tx_hwtstamp_skipped++; > + spin_unlock_irqrestore(&adapter->ptp_tx_lock, > + lock_flags); > + return; > + } [...] > > +static void igc_ptp_free_tx_buffer(struct igc_adapter *adapter, > + struct igc_tx_timestamp_request *tstamp) > +{ > + if (tstamp->buffer_type == IGC_TX_BUFFER_TYPE_XSK) { > + /* Release the transmit completion */ > + tstamp->xsk_tx_buffer->xsk_pending_ts = false; > + tstamp->xsk_tx_buffer = NULL; > + tstamp->buffer_type = 0; > + > + /* Trigger txrx interrupt for transmit completion */ > + igc_xsk_wakeup(adapter->netdev, tstamp->xsk_queue_index, 0); Just curious because I didn't find it. Fairly sure I just need to look more, but don't you want to still 'tstamp->skb = NULL' in this path somewhere? It looks like triggering the tx interrupt again with buffer_type == 0 wouldn't do the null. I suspect I just missed it.