public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleksij Rempel <o.rempel@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: linux-can@vger.kernel.org, Marc Kleine-Budde <mkl@pengutronix.de>,
	Jakub Kicinski <kuba@kernel.org>,
	Vincent Mailhol <mailhol@kernel.org>,
	netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Simon Horman <horms@kernel.org>,
	davem@davemloft.net
Subject: Re: [can-next 0/5] can: remove private skb headroom infrastructure
Date: Wed, 14 Jan 2026 12:10:57 +0100	[thread overview]
Message-ID: <aWd5wdMhpEuN9NFB@pengutronix.de> (raw)
In-Reply-To: <20260112150908.5815-1-socketcan@hartkopp.net>

Hi Oliver,

On Mon, Jan 12, 2026 at 04:09:03PM +0100, Oliver Hartkopp 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. To store the data for CAN specific use-cases
> unused space in CAN skbs is used, namely the inner protocol space for
> ethernet/IP encapsulation.
>
> [1] https://lore.kernel.org/linux-can/20260104074222.29e660ac@kernel.org/
>
> Oliver Hartkopp (5):
>   can: use skb hash instead of private variable in headroom
>   can: move can_iif from private headroom to struct sk_buff
>   can: move frame length from private headroom to struct sk_buff
>   can: remove private skb headroom infrastructure
>   can: gw: use new can_gw_hops variable instead of re-using csum_start
>
>  drivers/net/can/dev/skb.c | 45 ++++++++++++++++-----------------------
>  include/linux/can/core.h  |  1 +
>  include/linux/can/skb.h   | 33 ----------------------------
>  include/linux/skbuff.h    | 27 +++++++++++++++++------
>  net/can/af_can.c          | 35 +++++++++++++++++++-----------
>  net/can/bcm.c             | 13 ++++-------
>  net/can/gw.c              | 25 ++++++----------------
>  net/can/isotp.c           | 18 ++++++----------
>  net/can/j1939/socket.c    |  7 ++----
>  net/can/j1939/transport.c | 13 ++++-------
>  net/can/raw.c             | 14 ++++++------
>  11 files changed, 92 insertions(+), 139 deletions(-)

J1939 related part seems to work without regressions.
For j1939:
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>

Thank you!

Best Regards,
Oleksij

  parent reply	other threads:[~2026-01-14 11:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 15:09 [can-next 0/5] can: remove private skb headroom infrastructure Oliver Hartkopp
2026-01-12 15:09 ` [can-next 1/5] can: use skb hash instead of private variable in headroom Oliver Hartkopp
2026-01-12 15:09 ` [can-next 2/5] can: move can_iif from private headroom to struct sk_buff Oliver Hartkopp
2026-01-12 15:09 ` [can-next 3/5] can: move frame length " Oliver Hartkopp
2026-01-12 15:09 ` [can-next 4/5] can: remove private skb headroom infrastructure Oliver Hartkopp
2026-01-12 15:09 ` [can-next 5/5] can: gw: use new can_gw_hops variable instead of re-using csum_start Oliver Hartkopp
2026-01-14 11:10 ` Oleksij Rempel [this message]
2026-01-15 15:37 ` [can-next 0/5] can: remove private skb headroom infrastructure Paolo Abeni
2026-01-16 10:31   ` Oliver Hartkopp
2026-01-17 17:15     ` Jakub Kicinski
2026-01-18 12:53       ` Oliver Hartkopp
2026-01-21 12:55         ` Oliver Hartkopp
2026-01-21 14:37           ` Marc Kleine-Budde
2026-01-22 17:44             ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aWd5wdMhpEuN9NFB@pengutronix.de \
    --to=o.rempel@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=socketcan@hartkopp.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox