From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 919DE3A784A for ; Thu, 5 Feb 2026 10:54:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770288864; cv=none; b=W2qp2Kmg8xkSTe9rxajMRUw1Put1QOMKZy/vH+RnFWoHYn+Yz1q7rXlvRq3uNecTf0HarWNdrqr0S13eOFw+d0UZvU0ZbRerkPqznIREOvD/0a0f2JIA4HntTRS7E7ij9nruJDoZ71aNQ2Ab2BMsAgP4BYDkdOGkRaC+W7V3ccE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770288864; c=relaxed/simple; bh=k+pTK1Q/uGh4cj7VMlNWwrmjpCjS8qk/jUC6mnPt9wQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GzE0gBcNFtVbdKNU2FSMS3xjO/x1mbdCZybF2n0W3IR8ZHYXdPWAzCHhYHSHtOSpQ2M1xtk2twcm12opiCpuul1SMGn+0jE76JPAYbIqt0c9F9d+fsYqJTH+QMzM5EOyNbK+ox9XEms3pxkR01Jl3wjii751Vvf2oT0+uZVG6Vk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=WJRky7lm; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=eU3B/b4B; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="WJRky7lm"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="eU3B/b4B" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770288863; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S2GhoRMtY21T7Hae8QgeRuxP2YQ8+rtPygT7RO80dys=; b=WJRky7lm3yHrcG0tc8XzbkasUenzdJK8tGrtYkV/DTNpOg9375K+wP6oePP3jBgIFgwkBx +qNXpP7VNFO/AlebGv6f7uUepMWIP+sntPbn6E+QVyOKkuUyuNeEiHSW35Tr4/trdfel0B ZznxU9QGm37LvQLCurrTj05SBN6WYag= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-104-BsrVF_QvP56bmwn5yBW6Jw-1; Thu, 05 Feb 2026 05:54:22 -0500 X-MC-Unique: BsrVF_QvP56bmwn5yBW6Jw-1 X-Mimecast-MFC-AGG-ID: BsrVF_QvP56bmwn5yBW6Jw_1770288861 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-482ef3af991so4469535e9.0 for ; Thu, 05 Feb 2026 02:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770288861; x=1770893661; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=S2GhoRMtY21T7Hae8QgeRuxP2YQ8+rtPygT7RO80dys=; b=eU3B/b4B42IUxOLl8dOAQ/ViCcWHSnApjkoND1PEYIv/GIzB1Nnu5Cyx4l/iFbTKlg LRm2fJVkkLdNDel2RGWSAlKBW29b1a+9wToQ+ovgVEPa/aEQmAAvBqxOrJa9VLxoWp+i B0YRapXK4vnyqMcNYlV+xIJnP67Bo6JxzoiH3aAnNTE9/vQ05pmIhsKuW5aiCLBAerrU sgeNqOQ8+eQm/K1yL9s6PqBu/rd1tGvLzQIgRFJsD/eKw49mCgUyYZMN0gMaoks1wIH9 Aoel0I7/FHhn+xDEE22+pqD8cOQw14wSzOmQRJDEtHTOT3prQLVNmTqgtniDkGJmIkXI XK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770288861; x=1770893661; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=S2GhoRMtY21T7Hae8QgeRuxP2YQ8+rtPygT7RO80dys=; b=N16ReQsQ6HxEyPmttO5BaGH/5PRXRY1/6GaqOnz+dQZtjhYWkJV/g3liszuPL2unFs CLjYvl0LkCJp0V5hpkLpOfgyJj8/u3oYG6GR4Ts6C6ffD6TPnHtZ7vD6srBt+4jR9sAO EDIMvVuuHVnfq+56YUX55rBVUfNwo7L3iRVF72kQXVI4avie7LsFBOQrYOy09mBDnNXX 9p7FhHj/KvmIxvAP6HI9BuEm/4ptki6I6t8hRQ984vWv7lsDcbVDEE/fECkOe2iVBJql powynkkxOKbxZckpTJe5u6I8k7hI9bFjDQ9wJJhToIekvUxUWPpogtpXpiwadKuyOVzw 7cTg== X-Forwarded-Encrypted: i=1; AJvYcCXGyOchoMfX2Q0Jx/adsvlNo2aos/eaOPmrSgP4fCIqS1ewHr3xFIyvz+bgoYGhdVlqL9Qejt/mrmKZxjs=@vger.kernel.org X-Gm-Message-State: AOJu0YxoKotYm1WTYBe4IHslx0OguxVdc+EtfqjSe/MIqs9b/iwJ7uBo WOK1kq5ANRx/nWKKlGmKAqZ/jVIo+ToRAuJNeM5l5HG4liJQjLAJ9odQMPs2y3fc2kGBv+kqUIP ZnXveIYh1Av5WMgDxLQSjMRVMbky3Rad3izD0aiJhyQUk2dqHViFTimDgwAT7YO5uQg== X-Gm-Gg: AZuq6aKlSz/nSRuWgtxzC13Pn8YYN7Ed727OaBbZl78ZIGyBIn0sNxSWyFTvP1A2yAk P4l3boPSUjVRZ9tbSxepQbT3N4jQ/IUFYHQAsi6OmecqWpyPuHVGX3QfbgPm46V5gvRXHZeJ1Fx /zA/df+h9RPaRgPwXDFDe3dlnkc7gA32BkmN7ILUG3v/qO0O6xsq09ZMreHr3UwYwSRw1uldBot D8RyybWgtQkeN565a1AqQoq2APfZcacP+YQyf/19iuwkaJ9Ot63HNngpTuSELZgKm4TtnNnI3gB ysoRTapW2bZm9Vh+Fh40pQChzb7WjFWyxAxVIlnjHT770OsjHHvrR7UVL5iXdxrSTa2Pbyjm14O +mZHJCNQh3eiU X-Received: by 2002:a05:600c:3041:b0:477:9a61:fd06 with SMTP id 5b1f17b1804b1-483178ebf68mr21654055e9.8.1770288861096; Thu, 05 Feb 2026 02:54:21 -0800 (PST) X-Received: by 2002:a05:600c:3041:b0:477:9a61:fd06 with SMTP id 5b1f17b1804b1-483178ebf68mr21653855e9.8.1770288860697; Thu, 05 Feb 2026 02:54:20 -0800 (PST) Received: from [192.168.88.32] ([216.128.11.114]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4831d0b5b31sm21336375e9.4.2026.02.05.02.54.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 02:54:20 -0800 (PST) Message-ID: Date: Thu, 5 Feb 2026 11:54:18 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v8 0/6] move CAN skb headroom content to skb extensions To: Oliver Hartkopp , Florian Westphal , Marc Kleine-Budde , Vincent Mailhol , Robin van der Gracht , Oleksij Rempel , kernel@pengutronix.de, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman Cc: linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kernel test robot References: <20260201-can_skb_ext-v8-0-3635d790fe8b@hartkopp.net> <7d544645-8699-409f-89c0-6fc606113627@redhat.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/3/26 8:19 PM, Oliver Hartkopp wrote: > On 03.02.26 15:40, Paolo Abeni wrote: >> On 2/1/26 3:33 PM, Oliver Hartkopp via B4 Relay wrote: >>> CAN bus related skbuffs (ETH_P_CAN/ETH_P_CANFD/ETH_P_CANXL) simply contain >>> CAN frame structs for CAN CC/FD/XL of skb->len length at skb->data. Those >>> CAN skbs do not have network/mac/transport headers nor other such >>> references for encapsulated protocols like ethernet/IP protocols. >>> >>> To store data for CAN specific use-cases all CAN bus related skbuffs are >>> created with a 16 byte private skb headroom (struct can_skb_priv). Using >>> the skb headroom and accessing skb->head for this private data led to >>> several problems in the past likely due to "The struct can_skb_priv >>> business is highly unconventional for the networking stack." [1] >>> >>> This patch set aims to remove the unconventional skb headroom usage for CAN >>> bus related skbuffs and use the common skb extensions instead. >>> >>> [1] https://lore.kernel.org/linux-can/20260104074222.29e660ac@kernel.org/ >> >> Could you please share how skb_ext size change with this series? >> (possibly breaking down the actual size to each separate extension). >> >> Ideally/hopefully the skbuff_ext_cache size is not going to change, and >> that would ensure that this change will not cause any indirect regressions. >> >> /P > > I'm not really sure what your question is about and how I could actively > change the impact of this series. > > When CONFIG_CAN is enabled the skbuff_ext_cache element would increase > in size by 8 bytes (sizeof(struct can_skb_ext)) on my machine (see > pahole output below). > > So when everything is enabled it would be > > CONFIG_SKB_EXTENSIONS > 8 bytes sizeof(struct skb_ext) > CONFIG_BRIDGE_NETFILTER > 32 bytes sizeof(struct nf_bridge_info) > CONFIG_XFRM > 88 bytes sizeof(struct sec_path) > CONFIG_NET_TC_SKB_EXT > 16 bytes sizeof(struct tc_skb_ext) > CONFIG_MPTCP > 32 bytes sizeof(struct mptcp_ext) > CONFIG_MCTP_FLOWS > 8 bytes sizeof(struct mctp_flow) > CONFIG_INET_PSP > 8 bytes sizeof(struct psp_skb_ext) > CONFIG_CAN > 8 bytes sizeof(struct can_skb_ext) > --------- > 200 bytes total skbuff_ext_cache element size > (255 * 8 = 2040 bytes max space for skb extension users). > > Does this answer your question? Yes, thank you for the collaboration! I think there is mistake above: sizeof(struct skb_ext) should be 16 when more than 3 skb extensions are enabled. that means that the total extension size already exceeds the 3 cachelines (192 bytes) boundary when all extensions are enabled and adding the CAN one should not cause any regressions is such scenario. Note that the "all skb extensions enabled" is possibly/likely NOT the most common/relevant one, but I think there is some space we can squeeze elsewhere if needed. TL:DR; LGTM! Thanks, Paolo