From: sashiko-bot@kernel.org
To: "Linus Walleij" <linusw@kernel.org>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH net-next v11 2/4] net: dsa: tag_ks8995: Add the KS8995 tag handling
Date: Thu, 10 Sep 2026 17:01:17 +0000 [thread overview]
Message-ID: <20260910170118.03DCD1F00899@smtp.kernel.org> (raw)
In-Reply-To: <20260909-ks8995-to-ksz8-v11-2-0e04411a559d@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Insufficient `.needed_headroom` causes expensive SKB reallocation on the transmission fast-path for VLAN-tagged packets.
--
commit f2aa1666092956329d185ea98c072903551a8a85
Author: Linus Walleij <linusw@kernel.org>
net: dsa: tag_ks8995: Add the KS8995 tag handling
This commit adds a new DSA tag driver for the Micrel KS8995 switch. It
pushes a modified 802.1Q tag on transmission and untags it on reception,
incorporating any hardware-accelerated VLAN tags into the packet payload.
> diff --git a/net/dsa/tag_ks8995.c b/net/dsa/tag_ks8995.c
> new file mode 100644
> index 0000000000000..f6ef1ef1891fd
> --- /dev/null
> +++ b/net/dsa/tag_ks8995.c
[ ... ]
> +static struct sk_buff *ks8995_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
[ ... ]
> + /* The switch expects the special tag at offset 12. Move any hardware
> + * accelerated VLAN tag into the payload so the conduit cannot insert
> + * it outside the special tag.
> + */
> + if (unlikely(skb_vlan_tag_present(skb))) {
> + skb = __vlan_hwaccel_push_inside(skb);
> + if (!skb)
> + return NULL;
> + }
> +
> + /* Always add a distinct outer tag. The user port removes this field on
> + * egress, so reusing an existing 802.1Q tag would consume that VLAN tag.
> + */
> + skb = vlan_insert_tag(skb, KS8995M_STPID(portmask), 0);
[ ... ]
> +static const struct dsa_device_ops ks8995_netdev_ops = {
> + .name = KS8995_NAME,
> + .proto = DSA_TAG_PROTO_KS8995,
> + .xmit = ks8995_xmit,
> + .rcv = ks8995_rcv,
> + .needed_headroom = VLAN_HLEN,
[Severity: Medium]
Does this code reserve enough headroom for the worst-case transmission path?
When an SKB is transmitted via ks8995_xmit() with a hardware-accelerated
VLAN tag, the driver first pushes the hardware tag into the payload via
__vlan_hwaccel_push_inside() which consumes 4 bytes of headroom. It then
inserts the custom KS8995 switch tag via vlan_insert_tag(), consuming
another 4 bytes. This requires a total of 8 bytes of headroom.
Because needed_headroom only requests 4 bytes (VLAN_HLEN), if an SKB arrives
with exactly the requested headroom (such as when forwarded from another
interface), will the second tag insertion exhaust the headroom and trigger
an expensive SKB reallocation on the fast-path?
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-ks8995-to-ksz8-v11-0-0e04411a559d@kernel.org?part=2
next prev parent reply other threads:[~2026-09-10 17:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-09 17:00 [PATCH net-next v11 0/4] net: dsa: microchip: Add support for KSZ8995XA/KS8995XA Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 1/4] dt-bindings: net: dsa: microchip: Add KSZ8995XA Linus Walleij
2026-09-10 20:01 ` netdev-bot+sashiko
2026-09-10 20:29 ` Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 2/4] net: dsa: tag_ks8995: Add the KS8995 tag handling Linus Walleij
2026-09-10 17:01 ` sashiko-bot [this message]
2026-09-10 19:57 ` Linus Walleij
2026-09-10 20:01 ` netdev-bot+sashiko
2026-09-09 17:00 ` [PATCH net-next v11 3/4] net: dsa: microchip: Support Microchip KSZ8995XA / KS8995XA Linus Walleij
2026-09-10 17:01 ` sashiko-bot
2026-09-10 19:56 ` Linus Walleij
2026-09-10 20:02 ` netdev-bot+sashiko
2026-09-10 20:53 ` Linus Walleij
2026-09-09 17:00 ` [PATCH net-next v11 4/4] net: dsa: ks8995: Delete surplus driver Linus Walleij
2026-09-10 20:02 ` netdev-bot+sashiko
2026-09-10 20:40 ` Linus Walleij
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=20260910170118.03DCD1F00899@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linusw@kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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