From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f47.google.com (mail-yx1-f47.google.com [74.125.224.47]) (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 75F3B3382E7 for ; Wed, 4 Mar 2026 23:48:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772668102; cv=none; b=okHSZXhQgxpSs3p/6wSu1ZbqcDYQrn1xtAVAPSUH5Pr47ZRdQ2q26b/y/RnprcZwKHF+KQ7vImevVJZ9u8TyhDYyutIn0eEixHyMym9nh6D/VXlkhbTYZmou2eUVngNCkzknILozwq8ayPQkIIYnzKGd8DwhYPzK4PbzPweWmMo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772668102; c=relaxed/simple; bh=gQZA4VyD57UEiZd0Im6sXhICW0i1Hw90ECCJj5wbPcY=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=A9d51fwSME31y2AyjY6ZI3xPHRMSE6JEAQQ+9YN+HX7HwM8+CzHeGYURaSMXji5NWB2q2PNSo7Z6D1yUY993cd17DCbnyTBONJEf+TNTp6BhMjkQoFr9L9Rouio8+9OlCD851HqG5gbKJe4o8veiu/qBJl37IQcoooCCi50YOgs= 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=GAh8O95W; arc=none smtp.client-ip=74.125.224.47 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="GAh8O95W" Received: by mail-yx1-f47.google.com with SMTP id 956f58d0204a3-64ad8435f46so7081139d50.1 for ; Wed, 04 Mar 2026 15:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772668100; x=1773272900; 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=OTfN7Kdw2uDWmWP2MPCQ81Cs0QrBTRruM2tmDixgOLA=; b=GAh8O95W7fpQcSfRGb43E9LH5ul895AnKq+roLxOPjmReFsSuOAzKbcjV9af4mlnWT DaP7hTIQk81zZYnKBqZGxEQx78UyoOIPlW077IWwydNJEJFRGyFFzwsk/R5ADefc5BtC ChWQvl3yaPNMpOCRXUum9W+bp4TfOKF6fCipCtQhjU0BLoo2ccVXPs+iHbNsmyicAydj AXx8o0sRWWBG4oXUdoRajcKQ5q+dajjO6yjpI0QMk84nYdIJSzRztSbKTgOOwYi8hUKQ GmDv6rv6Tf/kxPNd9C8B4MZPOrV6m3MhXNj+0eVCsJkfUnyBz2yywnPNcnpYT1I+djmN X8cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772668100; x=1773272900; 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=OTfN7Kdw2uDWmWP2MPCQ81Cs0QrBTRruM2tmDixgOLA=; b=XRCqRVDKTA63ms1lmRJnjQgvdc0SnHP2ChfJPBp1jx5ZUBGwlDuJtqi2Bj47J6ueXy zbC8reFAuOdw/VHlj08hvXR4fXF7FjwJNIhZL/NNPaEfug1ciobMdsHKR5BfGHrCA7UL HkXApIdvFQfn1pTB2kLbKedW255EZ8mDo4zj6stqZP8iiZCxUo8V+31A1PzA4kH/8vJt NwOzmivKdnCXfxHR/3YCckLKeXokPHqoqt1OGVcExzdAzO6YcYkpT7T/cIlp+kMAkU9r 4h+YYeWK5cHpiwqq59rhehDCmhpHOIvASgxACuyb87s39mXamQ6D0SMS8Pb2Mp3nbtlx dpeQ== X-Gm-Message-State: AOJu0YyOF3+fCZAs+jAgadhxySBNKYbNx5X/qZM3eiPPgSizdhOHDDvP 6oxhyA9tyjyMOd/A7OOvn88edHd1L7S2UEKryz40OaLLsxFEU7AhimxJ X-Gm-Gg: ATEYQzydt36dpkTQhokq6VTRaX5bs99FX5L8hH+JM968rzG/ufuleISIJNKrsWyLI/6 mkjZr+7n0iZ8rxyhbpzafwpQonYWPiU5n1qRu4jKF+v51cdtqlYBiz8AFjmm+AeGf6iEEPdnFkU 8Uj3ThJjzBLYCMEdLh9NJBiT/nqYNdUnNMcR7WAq8JSsm0G/qrAdlS3BKGiPlp0hcpsQRE1cvVv BCEb0tGSZytIZO9b2mx52Plaj4tsv/IXVi27ZOD8/tcn0llg6WQw3Ou/O/hxUgsFU9DIYPbFC8P FyUNky/hQqX7EkyNHEUptiildtrQOJJbtEzut04bz08Eaexa4uiXPDMuPwq4FBHhmCIeq/zitOq dvlE3OPRzflB9ZVp2VY5B1V/sD89h1eW083tIoTCnmTSj4YuspKDgY1ojX/U4C9NtcyTFe+ht5V BA1xQYIy83cMcdFMyrMh9ZlD0HAA05xTVNYevx128yf8BjEm4Limlt4qlW3iCEhRB8KRwvfRI= X-Received: by 2002:a05:690e:444c:b0:649:be95:aada with SMTP id 956f58d0204a3-64cf9bd901bmr2375679d50.69.1772668100579; Wed, 04 Mar 2026 15:48:20 -0800 (PST) Received: from gmail.com (15.60.86.34.bc.googleusercontent.com. [34.86.60.15]) by smtp.gmail.com with UTF8SMTPSA id 956f58d0204a3-64cb75a1157sm8670552d50.6.2026.03.04.15.48.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 15:48:20 -0800 (PST) Date: Wed, 04 Mar 2026 18:48:19 -0500 From: Willem de Bruijn To: Sebastian Andrzej Siewior , Willem de Bruijn Cc: netdev@vger.kernel.org, Andrew Lunn , "David S . Miller" , Eric Dumazet , Felix Maurer , Jakub Kicinski , Paolo Abeni , Richard Cochran , Simon Horman Message-ID: In-Reply-To: <20260304161255.VV_7vPBw@linutronix.de> References: <20260204-hsr_ptp-v1-0-b421c69a77da@linutronix.de> <20260204-hsr_ptp-v1-1-b421c69a77da@linutronix.de> <20260304145821.TQhzhhjF@linutronix.de> <20260304161255.VV_7vPBw@linutronix.de> Subject: Re: [PATCH RFC net-next 1/2] hsr: Allow to send a specific port and with HSR header Precedence: bulk X-Mailing-List: netdev@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-03-04 10:56:16 [-0500], Willem de Bruijn wrote: > > Sebastian Andrzej Siewior wrote: > > > Would it be okay if I occupy three bits in sk_buff which look unused? > > > > Have you looked into using skb_extensions? > > Yes. I would have allocate memory via __skb_ext_alloc() and attach it to > the skb via __skb_ext_set(). That would on receive and while sending > (via af_packet). > Looking at the current allocations as of skb_ext_type_len, they all need > a bit of memory, the smallest is mctp_flow with just a pointer the other > are a fair amount larger. For the three bits, I was hoping to avoid it. But this is not a performance sensitive path, right? Nor is it very complicated to add? I understand your preference. It's just that if every protocol and feature, let alone their cross-product, adds a few bits to struct sk_buff, it grows to become unmangeable. A classic tragedy of the commons. For this reason pushback is common. Devil's advocate, an alternative would be to add a few bits, then maybe union them so that other users can use the same bits as long as their code does not overlaps. This quickly becomes hard to analyze for correctness. In a sense skb extensions resolved some of this. That said, happy to hear other opinions or implementation concerns that I may have underappreciated, e.g., it may not address the HSR specific needs for AF_PACKET.