From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (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 2F21E4266A2 for ; Wed, 27 May 2026 15:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896383; cv=none; b=Nc6YKVTzKtGnf4n5u9ippl/xy8IvIfY/S6bfMaGYj6hEVV1Pu8+BXOmkDw/pmoRwgo7fa2JFF9n2j5NQxmI8jzMVDhmN8o4OOaw+APnpQsjJpkoWgvmPYxXiX6MdA2VHaBLyxDwJ0D1Mh3/kKZFwBNPF8tm2gdAvUj/ozERWg/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779896383; c=relaxed/simple; bh=onG1RawqFcI8NnhLU4G5xlXfAOmprRvmPVBmdp31/80=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s4sos5l/g8q6fTMVSEHVaDEALKGjEjmirp0IRWOSIKfRcEyFH5VN0vSa5Fgj07c5anejswh+hGe1GuR7D3TC8RLhZkNBjBVAlT1Q/LZHlO/K1Q+du69KsKaJOKipckJvik2Co9mdGh2qqkomminDjgxn9IpjaIc5d32IRmdlj94= 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=A4/H3fCt; arc=none smtp.client-ip=209.85.218.54 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="A4/H3fCt" Received: by mail-ej1-f54.google.com with SMTP id a640c23a62f3a-bd8f9889a8cso1417638866b.1 for ; Wed, 27 May 2026 08:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779896380; x=1780501180; 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=S0daKFRaEmuHFhe11WXYlg2kJgS3CypnETaj1XfTD4g=; b=A4/H3fCt5PNt3vNNcRnjd8AToa27YHRdnxJPuWORfzcvaq+W8ejpkaq+WzszdWKtDa h/breJbeyOpCEoGfW6bb0Fpf1A1E4hbzQLFzaqi9QMgcw+931MBTrQhh5r8qXTwLiIb8 Va7i4ALvoE0BeUWE1E0s/Ip/x94p9cE45Q/VIynl79tXr1WIZ/nC0BNmMjOSJoh6yepT rmGYJ52wVLfmABWENjSGGNOSL4vVqGlXubN2lYd6SD0PLb8U3VxiHhsnESEGhCNNkali xlna+NtmRsPjqWYkb8P960u5ugpxlGGGXZQrpHxa6phOoNM23zW5do5j8aXnXDm5s+zM wBIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779896380; x=1780501180; 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=S0daKFRaEmuHFhe11WXYlg2kJgS3CypnETaj1XfTD4g=; b=JeQcghT+C8UbtGtC9Aqg4zj18E5o7c3bxxfwAtFmOQ/z5kQy0aByNpES2vgVdRrCFF HDdaCvojZbRj7FJQGqd+9Gy46x/FkNAJlAOO+lSaHm/0q6lbxDvJJATZ2ahMR7dLKkkf eT/irMPERhWveFBXO0quI4+0mwhCYKKpUsvzyvt9PFYiFFQouJE8s2BJ8aKPrHFiqQGH zVpZgNn/QtmDrXOmqXi0iAnlN/wuZdyO7LiuxkvqoQbxWWDQVZkBHsyv/WRkI3Ve43Va o1OZwNbCW0YOU0zuFXvnPfGWAK129cnP/xL/6EUvovNpYXZ/QwS18yTshrpGbXWjOVif 5Axg== X-Gm-Message-State: AOJu0YyfAUmny6Jkx6Xdgn4rGSlDHgqE1npTpa9KPOewcg81ZoUmFQMa rcU82khK1pnXN4ncKfSJS4ArAMWJo6TPrxkBpQdwoJDrtM0XVib7VX4H X-Gm-Gg: Acq92OH1FgHrUFoEKBOKPbI3MnA58tvhbvDy7kTJrX/wzuwTKKevZJ95ClU8lPTUQW8 edQzsaK4UUUyNPmT1KfxsmwfX8Av3zQhebRfLEeKsIPU/pAJ0U7VTxoUeHeDHZorNJPPpmL+9nS 8Nd73AMCKOgQSUwQJY0bU8p38F3761l6uzElH3gJSyBtdpXFXpZfK6mCGPlAtKDS4d3jijcBsEq bY71gAFWEuD6eVhSSo0Nye5MZetJrz8978qnqRiyeojl+px52KS8Zi8vW/KfCBot5ruJ36p8pNI MUKyuE53J4/2U+ftmowrlbc31+4X2+rwj80iOYXDPU75BIZqizD7zpe0DZvBzfOgW7Q1v2/Vjre SGZ+fjMMucm1vw+KUpuKcaOxNfA/VugjK6C3PkGj3/YcYYNhGAUd5dCreye7QST5wF4P+EFJxyn nPYYJtj9+CaCMbI9hCMnF3+9xC0HqUkdllEheB7AMXa+Ht9actEqBl2IGID/G2+SPtEBcfSc13C XxUj75IxqnquUGh3K1v+9oaIUVwXVuOEw581AcSkSvjL3vGNoBbqnZFO3/XHGsNWW+d0idQ1KHG IWlJ6js5mfRhwZe3o48= X-Received: by 2002:a17:907:b5a3:b0:bce:4be4:cb9e with SMTP id a640c23a62f3a-bdd25ce0c02mr1052749566b.24.1779896379332; Wed, 27 May 2026 08:39:39 -0700 (PDT) Received: from [192.168.0.2] (dslb-002-205-016-123.002.205.pools.vodafone-ip.de. [2.205.16.123]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bddc30528a7sm626790066b.21.2026.05.27.08.39.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2026 08:39:38 -0700 (PDT) Message-ID: <2bcddaf2-e3b4-4f72-ae2d-1ac22c2e7553@gmail.com> Date: Wed, 27 May 2026 17:39:37 +0200 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 v6 1/9] net: dsa: add tag driver for LAN9645X To: =?UTF-8?Q?Jens_Emil_Schulz_=C3=98stergaard?= , UNGLinuxDriver@microchip.com, Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Woojung Huh , Russell King , Steen Hegelund , Daniel Machon Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org References: <20260527-dsa_lan9645x_switch_driver_base-v6-0-4d409ae64f3c@microchip.com> <20260527-dsa_lan9645x_switch_driver_base-v6-1-4d409ae64f3c@microchip.com> Content-Language: en-US From: Jonas Gorski In-Reply-To: <20260527-dsa_lan9645x_switch_driver_base-v6-1-4d409ae64f3c@microchip.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On 27/05/2026 16:49, Jens Emil Schulz Ãstergaard wrote: > Add tag driver for LAN9645x using a front port as CPU port. This mode > is called an NPI port in the datasheet. > Use long prefix on extraction (RX) and no prefix on injection (TX). A > long prefix on extraction helps get through the conduit port on host > side, since it will see a broadcast MAC. > > The LAN9645x chip is in the same design architecture family as ocelot > and lan966x. The tagging protocol has the same structure as these chips, > but the particular fields are different or have different sizes. > Therefore, this tag driver is similar to tag_ocelot.c, but the > differences in fields makes it hard to reuse. > > LAN9645x supports 3 different tag formats for extraction/injection of > frames from a CPU port: long prefix, short prefix and no prefix. > > The tag is prepended to the frame. The critical data for the chip is > contained in an internal frame header (IFH) which is 28 bytes. The > prefix formats look like this: > > Long prefix (16 bytes) + IFH: > - DMAC = 0xffffffffffff on extraction. > - SMAC = 0xfeffffffffff on extraction. > - ETYPE = 0x8880 > - payload = 0x0011 > - IFH > > Short prefix (4 bytes) + IFH: > - 0x8880 > - 0x0011 > - IFH > > No prefix: > - IFH > > The format can be configured asymmetrically on RX and TX. > > The IFH get/set functions are declared as inline. All the field > constants are compile-time known, so when these calls are inlined > efficient code is generated with branches pruned and loops unrolled. > During testing it was observed that without explicit inlining GCC would > have trouble inlining the functions, which hurt performance. > > Reviewed-by: Steen Hegelund > Signed-off-by: Jens Emil Schulz Østergaard (snip) > +static struct sk_buff *lan9645x_rcv(struct sk_buff *skb, > + struct net_device *ndev) > +{ > + u32 src_port, qos_class, vlan_tci, tag_type, popcnt, etype_ofs; > + struct dsa_port *dp; > + u32 ifh_gap_len = 0; > + u16 vlan_tpid; > + u8 *ifh; > + > + /* DSA master already consumed DMAC,SMAC,ETYPE from long prefix. Go back > + * to beginning of frame. > + */ > + skb_push(skb, ETH_HLEN); > + > + if (unlikely(!pskb_may_pull(skb, LAN9645X_TOTAL_TAG_LEN))) > + return NULL; > + > + /* IFH starts after our long prefix */ > + ifh = skb_pull(skb, LAN9645X_LONG_PREFIX_LEN); > + > + popcnt = lan9645x_ifh_get(ifh, IFH_POP_CNT, IFH_POP_CNT_SZ); > + etype_ofs = lan9645x_ifh_get(ifh, IFH_ETYPE_OFS, IFH_ETYPE_OFS_SZ); > + src_port = lan9645x_ifh_get(ifh, IFH_SRCPORT, IFH_SRCPORT_SZ); > + tag_type = lan9645x_ifh_get(ifh, IFH_TAG_TYPE, IFH_TAG_TYPE_SZ); > + vlan_tci = lan9645x_ifh_get(ifh, IFH_TCI, IFH_TCI_SZ); > + qos_class = lan9645x_ifh_get(ifh, IFH_QOS_CLASS, IFH_QOS_CLASS_SZ); > + > + /* Set skb->data at start of real header > + * > + * Since REW_PORT_NO_REWRITE=0 is required on the NPI port, we need to > + * account for any tags popped by the hardware, as that will leave a gap > + * between the IFH and DMAC. > + */ > + if (popcnt == 0 && etype_ofs == 0) > + ifh_gap_len = 2 * VLAN_HLEN; > + else if (popcnt == 3) > + ifh_gap_len = VLAN_HLEN; > + > + skb_pull(skb, LAN9645X_IFH_LEN); > + > + if (unlikely(!pskb_may_pull(skb, ifh_gap_len + ETH_HLEN))) > + return NULL; > + > + skb_pull(skb, ifh_gap_len); > + skb_reset_mac_header(skb); > + skb_set_network_header(skb, ETH_HLEN); > + skb_reset_mac_len(skb); > + > + /* Reset skb->data past the actual ethernet header. */ > + skb_pull(skb, ETH_HLEN); > + > + /* We must deliver the skb so skb->csum only covers the data beyond the > + * real ethernet header. The fake ethernet header in the prefix is > + * not part of skb->csum already. We must subtract what remains of the > + * prefix, the ifh and the gap. > + */ > + skb_postpull_rcsum(skb, > + skb->data - LAN9645X_TOTAL_TAG_LEN - ifh_gap_len, > + LAN9645X_TOTAL_TAG_LEN + ifh_gap_len); > + > + skb->dev = dsa_conduit_find_user(ndev, 0, src_port); > + if (WARN_ON_ONCE(!skb->dev)) { > + /* This should never happen since we have disabled reflection > + * back to CPU_PORT. > + */ > + return NULL; > + } > + > + dsa_default_offload_fwd_mark(skb); Does the switch (by default) also flood link local traffic (e.g. STP, LACP, etc)? If not, you should not mark these as fwd offloaded so that the kernel knows that it needs to do that in software if requested. Is there is a bit in the header that says whether a packet was flooded or trapped to CPU that you can check? Best regards, Jonas