From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com [209.85.128.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E26A538944E for ; Tue, 10 Feb 2026 16:14:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770740060; cv=none; b=DwRd+8mOCHplpaOs+GJUW+n/AOKLYbJFzd59s9/OcY28RBIrI/j7+0nR+UXyx9p0Xiyb3ulYiRYoMMIEaGiIx/SE97PyTrvr8r4wQXExGcqcXxNAp8o7d/4tf3J0f+takN0YULeauRS0vd6yP1+nXjcgJpKrBWwwZsaGbiyi+co= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770740060; c=relaxed/simple; bh=CXytLxrI9iUQwr2VbzFGCBUnkWtdUiReWQUTzH2PPdY=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=oTe1HLCRiJIygsbA4kV9kMyFFe+ZrKcVE3LrfXlNS98MW6VlnULR2hGYszYLH1m/m25ANTn1FYSBf11GT+HYibLbnc3WMQNP+NobXF9RuS9bQ0VJ6KubttYJxPeeIoggoMgK3H0LoekRAJfSUcWoKQVgDX1QSe2AAT1cPxpNLyw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZfXhkwDo; arc=none smtp.client-ip=209.85.128.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZfXhkwDo" Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-79639c2ceb6so28090757b3.1 for ; Tue, 10 Feb 2026 08:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770740057; x=1771344857; darn=vger.kernel.org; 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=gchGUW1rkpuZA2Rc75u+DqHEmEZ2JQMqcNEoDXirPgQ=; b=ZfXhkwDoWaY2H7rHC6Sck6TzKOE1Yec8KHIv/FhnNdLSw8WfeWJ0Xj/bTycvj9j72o gp0L+zsRCAJo0YWWXHUBESLk3I2l8nddBBKC+0+U4t0EEghtnNdsRpDcj+04uQGjzYre d9iEW5cd3kI2vHcYrK7pjXHR9eNbJ+PpDL11jui+K7hWqOKdOhE9ZSKJz1I7D9cxWpe4 hJHpB8gdLJEoS3VWUit3AesvuCjRtIFJgLXkTbnvG10AwUmhKFM+ECCeptut4NnqVhVF nmWIFNr+qxPGeVXusHalXgJzz6MWg72Mj1F91JGbXgZBMcNzmwDJFOxYkU2OScG4ST8Z lNHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770740057; x=1771344857; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=gchGUW1rkpuZA2Rc75u+DqHEmEZ2JQMqcNEoDXirPgQ=; b=Il8GWqQEpqfpNoIR6i76EseSwkoW9kiNDqV6lDajorlb42axZF7Nh4euNPJ1tou7x6 dAhjB83cJa4cKwxaUH5j8eM9polhJoNkeVY6vWlO032NU6j1dhxsptnbHVTSotKqGrJy 4Ve1bOjsSyqYERoeZ2VIeHL6GDbbyv71Nq+yJZ6fEg7EZEqkbVn/o5RiJH79bf+OhUBV sahFOtVAxGOmuFWcNuOB4avJhYz5fOIshzopvKmW4p1Y5jmWe9sT/eIfPphMQMr5Rzf/ XjYgXJVSUYjGCTpn5xm3gwiOZ/JWNDcfsKgzhA6Qp2AyioE3R+lkTKctMT/6CHh7QI1G qcng== X-Forwarded-Encrypted: i=1; AJvYcCUjEFtlVGZCNTdXyyOJ7KHsrfMcPB9DujgcXWTHmWBirS0zvJAqyNHxgEhFudCqO1m7hxO3gIB4+vG3YOk=@vger.kernel.org X-Gm-Message-State: AOJu0YwS6xU9C9PeKRkOuawfvTyOU4Ini8kjfKlwmXRWVpy84cBWbn/g zwPVlaUN2niIOQa6rYMj8jpT74f3h3WwquPPRsbp2s2q2Xbf2wq+kKVx X-Gm-Gg: AZuq6aKorXtEG+shIGYpcWakkwaAuDAALI7HmP9DcpzARbiemq1A76ei6Ydtc7tVZmB AjtiV0zf1e/jTM126ij1LKgxUS+K0UXm/TfP0NJU1Rmwjrn/zTK1JA3SSzJhKILiEyno+yceCvQ pYkBgch/bW6zLpOkNpadx/cMV503mZ5VbcTsM9D2v9iE3H/9F89JaQsJk8/fJCRHaCUMsNzhM72 MCZiho4GvTiIu6CJuq8P31ktMwax8k1+pAnkQSSHuFa35S+4GHFlL3/urTVqcsW9BsOxkYbWf7G aHiJ4ZY9IDoIFP6MX1V5INZBuc97z6TL9UrDagHyoKpSnYi/FEiHrdgjg3qBX8BizYH7P3sRI4q rKfoj4o+NyROdORvJ07t4hYjHHeAYGveY+vGMG3hvuTFSGKSHD7xCPYu86kDqcgYt95lmAA3Y9x xFohEf+M/MTz4+4UZov3cjbRXbCeOS7doAbCC1baxSQ8YSsJgIwNzy0wNR5ipzKHgKajEJkpI= X-Received: by 2002:a05:690c:c50b:b0:796:2fde:5dbe with SMTP id 00721157ae682-7962fde6696mr123516557b3.44.1770740056764; Tue, 10 Feb 2026 08:14:16 -0800 (PST) Received: from gmail.com (21.33.48.34.bc.googleusercontent.com. [34.48.33.21]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-7964cd48badsm49249307b3.19.2026.02.10.08.14.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Feb 2026 08:14:15 -0800 (PST) Date: Tue, 10 Feb 2026 11:14:15 -0500 From: Willem de Bruijn To: Sebastian Andrzej Siewior , Willem de Bruijn Cc: Vadim Fedorenko , Willem de Bruijn , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , "Loktionov, Aleksandr" , Kurt Kanzenbach , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Paul Menzel , "Gomes, Vinicius" , "netdev@vger.kernel.org" , Richard Cochran , "linux-kernel@vger.kernel.org" , Andrew Lunn , "intel-wired-lan@lists.osuosl.org" , "Keller, Jacob E" Message-ID: In-Reply-To: <20260210121207.9kLHroS0@linutronix.de> References: <20260205164341.pJvni8kA@linutronix.de> <76acd5cc-eb6f-4c56-a5e6-f6413736afbb@linux.dev> <601f0c4b-52d8-4b60-96bf-f2d65f8073d8@linux.dev> <20260209090621.GiZqTiMJ@linutronix.de> <8e762437-69f9-40d7-bb75-3a45bef1d5d6@linux.dev> <20260209114836.GPU-vnnh@linutronix.de> <78e2af2c-40e6-43f1-9471-42f350e69389@linux.dev> <20260210121207.9kLHroS0@linutronix.de> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx timestamp directly from interrupt for i210 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sebastian Andrzej Siewior wrote: > On 2026-02-09 07:46:01 [-0500], Willem de Bruijn wrote: > > > > Yeah, but what is the legacy user here? If you enable HW-timestamps but > > > > never set OPT_TSONLY and the sysctl is also 0 then you reply on the > > > > CAP_NET_RAW later on. Right? > > > > > > Legacy users here means users of HW TX timestamps expecting full skb to > > > be returned back with the TX timestamp. Legacy here means that skb will > > > be returned with headers modified by stack, which is kind of exposure of > > > data, which requires CAP_NET_RAW... > > Ah okay. I assumed the err-queue was the standard way of receiving > timestamps. It is, for tx timestamps. The open question is whether they are queued with or without packet payload. > > > > I just try to justify the CAP_NET_RAW check and if it is required to > > > > move it earlier (where HW timestamps are enabled). And if the sysctl > > > > check is enough then maybe it is not needed. > > > > > > Capabilities should not change during lifetime of the process, should be > > > fine to move. On the other, sysctl can be changed system-wide which may > > > affect users. > > > > Ignore the hardware configuration. That is entirely optional. Some > > devices will timestamp every packet. > > > > The capability check here is per-socket, independent from the system > > hardware configuration. > > > > I don't see how it could be moved. > > > > Before OPT_TSONLY was introduced packets were always queued with their > > payload. The sysctl check was added to optionally disallow this. The > > check could arguably be moved earlier in the socket lifecycle and the > > decision cached in the socket. But then flipping the sysctl would not > > affect existing sockets, so that is a change in ABI behavior. > > You could cache only the part under sk_callback_lock. Can you elaborate a bit? > Any other suggestions? > The access from IRQ is quick and avoids any detours. > The alternative would be to move the whole routine into an aux_worker. > For every driver doing it from the IRQ handler. Perhaps CAP_NET_RAW can be checked in a way that does not require this specific lock. See for instance other examples that instead use sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_RAW). Though that uses current_cred() so probably won't work in interrupt context. Changing the check may subtly change behavior. But that may be acceptable as long as the consequences are clearly described. An alternative would be to delay until dequeue. But that would wake the reader and then drop the packets, so without any data to read. Not practical. The core issue seems to be that the ptp_tx_work is not scheduled quickly enough. I wonder if that is the issue to be fixed. When/why is this too slow?