From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.tipi-net.de (mail.tipi-net.de [194.13.80.246]) (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 D6E6A37F012; Sat, 14 Mar 2026 19:48:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.13.80.246 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773517703; cv=none; b=E+nCjYN4/3exXv6lnyDcYZ2aiKFQb7FWayKNbyEVrwiH0YmnqnLQ3Qi6mK6OZxY+vpe79WD/b3Sk76iXdfbZniQPIBIVYSQqIjM4Rgl6maEbSYdrGXhc90ve/kPc9wn670iiLpA24Yde2Lhzi/YqFbhNrvHFZfwGBwq11hYELs0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773517703; c=relaxed/simple; bh=BRmPvP2djIc9Yo/5niOAz8y1AvHloANjfvMUPdo+SWM=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=tVEAPEV+kSML1lSleWV1st3i/tX5A+39POffSeIcfLBT1abV4vmfJt3+ML/VfOsthD3WaLhdyviL7l0IPgtBEAasDSud9PMiBm9cQxJuawUIKaa6+NGifApc4exgHVsoAMdDyYnBODcBeyacb3t5itxzkMBx+f53gqtNcrMcbTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de; spf=pass smtp.mailfrom=tipi-net.de; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b=jXlK+OI1; arc=none smtp.client-ip=194.13.80.246 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tipi-net.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tipi-net.de header.i=@tipi-net.de header.b="jXlK+OI1" Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 13C4FA03C2; Sat, 14 Mar 2026 20:48:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tipi-net.de; s=dkim; t=1773517692; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Ok9tNM7h4Im+PSk7ldF+1yMBmVwrI9z/4FmaPuam2SA=; b=jXlK+OI157yt4ln9lRiDcIv1qC7vYD569l4XzBCa9yOauwMXqkm/s5s1BB2xKJCeHyxZiZ O1ObJESiGZdEPfbKwkW/1OfMdqVwag2ee4J7wgZLBsx9pskeL31UlJHcxgQE1QoM03NC7C CyKPJPHjBnnUFyf6mUhRstJG3hNJWicpumeAyYR9ZiPOas3y3BKRkHrvHZVhT4NwMhBGQR 43FlK5J9MZGf/PaQrFd/iw3JdPHrf+F/ClstXRq/A9sHdGREipCPCwQ9KE9pqTux026yg4 lcyZSUgpjneMpi27GsOZ/9qfYR2LsetEVoBVQI8dbYELGs08nN0sRA0SH+Laew== Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Sat, 14 Mar 2026 20:48:07 +0100 From: Nicolai Buchwitz To: Florian Fainelli Cc: Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Doug Berger , Broadcom internal kernel review list , Vikas Gupta , Bhargava Marreddy , Rajashekar Hudumula , Eric Biggers , Heiner Kallweit , =?UTF-8?Q?Markus_Bl=C3=B6chl?= , Arnd Bergmann , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 3/6] net: bcmgenet: add basic XDP support (PASS/DROP) In-Reply-To: References: <20260313092101.1344954-1-nb@tipi-net.de> <20260313092101.1344954-4-nb@tipi-net.de> Message-ID: X-Sender: nb@tipi-net.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 13.3.2026 23:48, Florian Fainelli wrote: > On 3/13/26 02:20, Nicolai Buchwitz wrote: >> Add XDP program attachment via ndo_bpf and execute XDP programs in the >> RX path. Supported actions: >> >> - XDP_PASS: build SKB from the (possibly modified) xdp_buff and >> pass >> to the network stack, handling xdp_adjust_head/tail correctly >> - XDP_DROP: return the page to page_pool, no SKB allocated >> - XDP_ABORTED: same as DROP with trace_xdp_exception >> >> XDP_TX and XDP_REDIRECT are not yet supported and will return >> XDP_ABORTED. >> >> The XDP hook runs after the HW error checks but before SKB >> construction, >> so dropped packets avoid all SKB allocation overhead. >> >> Advertise NETDEV_XDP_ACT_BASIC in xdp_features. >> >> Signed-off-by: Nicolai Buchwitz >> --- > > [snip] > >> @@ -2345,12 +2397,6 @@ static unsigned int bcmgenet_desc_rx(struct >> bcmgenet_rx_ring *ring, >> hard_start = page_address(rx_page) + rx_off; >> status = (struct status_64 *)hard_start; >> dma_length_status = status->length_status; >> - if (dev->features & NETIF_F_RXCSUM) { >> - rx_csum = (__force __be16)(status->rx_csum & 0xffff); >> - if (rx_csum) { >> - /* defer csum setup to after skb is built */ >> - } >> - } > > Did you intend for that hunk to be deleted? Yes, (kinda) intentional. Patch 1 moved the csum setup after SKB construction (since we no longer have an SKB at that point), but left the early read as a dead no-op - patch 3 then removed it. I'll clean this up in v2 by dropping the dead block directly in patch 1 instead. Nicolai