From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f11.google.com (mail-pj2-f11.google.com [74.125.227.139]) (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 9950D49365F for ; Fri, 21 Aug 2026 17:28:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.139 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787333342; cv=none; b=aj4q3FVMEKinm4skFZHLpx8WP6NSoa9AMCKthflW7ZCN6sU8wSO++xGReqXrctUOdr8rRSJkO1vFnv3HwCrHLaEDYqe0TJVNtwpxgqY9ugb2euGQ5gn6GEwgHZallsLqwloHcRECRqge/dC4NivGlA5NO95BuFO2e29tgg5FLrU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787333342; c=relaxed/simple; bh=8RUjnU6xRjcmNvUjJtxfa9pOtsNBEqKceMyc7GHbth8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OBDzdSGSNhLlAuCecQtE1go6JEQVZYBROuo1yFK4QXj0E+4nxq7QR6zFTYc462o/fj2zjjLzG4XSjVdsVdTmpzc2zOTvUjQ/wlo7HHeOLfRn++v01mu0R9dQ4w4H6w4Zq9i7LtqKsokt7OjTKhHnQJ9JGgkywVGjD8ZBprTbCUU= 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=qNxgTY18; arc=none smtp.client-ip=74.125.227.139 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="qNxgTY18" Received: by mail-pj2-f11.google.com with SMTP id d9443c01a7336-2d59734a089so8363515ad.0 for ; Fri, 21 Aug 2026 10:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787333332; x=1787938132; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=+RpCheSrOdysr+r97ve0JN+xVtWYbZrCXCOuzISS1Oo=; b=qNxgTY18rOb7T0OC5VtF0SuhunEmmcsk/6gTTAGgDGaKIylfjtjTQnxeL6DngsqYDz zaDZTNMNmL/T82F72I3x60JxeumK3DKoSkRDl9R2GOaTyjmFXpQgDHi9UvURWtYAXQd8 2Ym+Hdi/6vKrBTZyNSBXCXyYdtE2J6NY6FgBnWJRp2icp4f/riSus4fp5f/SMYasIHvV mqJsgQ+nEynE7aO+ose+SBqN2r+VRf4hYMzI8mhVJQpLi2ggGitsfJM6CK7BbkQmOV6r pARfwYuZ0INZ9cMXZIJmNRGWXAqWgWOrecA/GmoHT4mA4iccPhmirpXnopgjHt5Squ0K 1rZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787333332; x=1787938132; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+RpCheSrOdysr+r97ve0JN+xVtWYbZrCXCOuzISS1Oo=; b=A9dSzbPUR84ikz0VvNQGFMNkokYoGdRAMpuxGDaExLcZj1Kr1DRslh6rGBAAPg3iFo ECaZCbCqQdMlegU0/qKS4obaXcm2IxQykF3WKDSnSOkL5ej4lLYhL9SwCXNJVIseVU7V lHZWemD5TQvFAwOauq31nQ48UfmTw/aBP0kpBrADJ56b63EWUqJ5LwL5gKQbNyY7VVxo 69J05/zUVjaEnXMWehx8JTTIEWMp8KQ8d67+RPrnH18xUPauF1U38fmdEPLBo+Dr27DN 6mUDdS9bZW4Of+Q2OOkaJm0oqAzhfQii5pI9lWnqlpDYAAz5Anrb/uOo4OE+VVQSosl2 DRnw== X-Forwarded-Encrypted: i=1; AHgh+RqEhgWGjWwKyCY7XXe1eYd2ORBbVk84jzpHRCDWB8ovB/fU6qg1Fh+l7GWivmq3KExtizpuKco05PgdXIQ=@vger.kernel.org X-Gm-Message-State: AFuF++l7dgR8B5LQkM5zxDpU+GnryZFKmABo8fTJ2D0WpAL5nwIki41g 6nIxz15dNeqgZXh6qaohXL0Sz06OKcmlOhA6EmSNtcSl90qAy0NAMmC/ X-Gm-Gg: AR+sD13ZljlJZ+mWsSt8irWpquXeSD/Dyaz3NuoHSEkxLkOiiZsrJugZkir1aEertZc smOjbti5XANF30YGGFrYP5wN1mZsv3ywHZ+8soEjPo1TJWCWqrg/dzbHCShC1HMDGV4TUsQWCRC yMWnaPH4i8k0XxnAseBMaCklCn9g6szby58mGmhIoQvcQShzW/IiOeYP/7Ki48+nKBhSMn71UcQ FZuENJ6tpkH3gz3rWcYGpxijpzo7ApmFfHbabOX/DbY+e4EGBOWMyk94rOmmSw0hp6VRQW3w9Fk ByQsaj19w1cZuFju1qRYb7rUKanUIjROQJUDr4hKsMMXBbGZQfBEVKSnPBPEmQzVG410kmi5x9Q bzAQa1c0n/sCssqho4ds/gpuTurZMGYrfLTS6LKwiXGwrbyzzqrebnb32hmdAtLMe/prHcianCh iTnxlphgeQQGYTppC958UUJz4zsVvuxxw/0pgHFfrQMcdanunHilTCxg== X-Received: by 2002:a17:902:e943:b0:2d6:3c2f:69b with SMTP id d9443c01a7336-2d64af6f8cemr156390915ad.8.1787333331890; Fri, 21 Aug 2026 10:28:51 -0700 (PDT) Received: from localhost ([2a03:2880:2ff:48::]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2d62d555b51sm21790945ad.7.2026.08.21.10.28.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 10:28:51 -0700 (PDT) Date: Fri, 21 Aug 2026 10:28:47 -0700 From: Stanislav Fomichev To: Maciej Fijalkowski Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com, andrew+netdev@lunn.ch, saeedm@nvidia.com, tariqt@nvidia.com, mbloch@nvidia.com, maxime.chevallier@bootlin.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, aleksander.lobakin@intel.com, horms@kernel.org, magnus.karlsson@intel.com, sdf@fomichev.me, ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com, guoren@kernel.org, dtatulea@nvidia.com, witu@nvidia.com, martin.lau@kernel.org, yoong.siang.song@intel.com, intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org, linux-csky@vger.kernel.org, leon@kernel.org Subject: Re: [PATCH net v3 3/3] net: stmmac: document oversized AF_XDP frame handling Message-ID: References: <20260819160535.1472459-1-sdf@fomichev.me> <20260819160535.1472459-4-sdf@fomichev.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On 08/21, Maciej Fijalkowski wrote: > On Thu, Aug 20, 2026 at 06:29:16PM -0700, Stanislav Fomichev wrote: > > On 08/20, Maciej Fijalkowski wrote: > > > On Wed, Aug 19, 2026 at 09:05:35AM -0700, Stanislav Fomichev wrote: > > > > stmmac drops AF_XDP zero-copy frames that exceed taprio's queueMaxSDU > > > > after xsk_tx_peek_desc() has reserved their completion entries. > > > > > > > > Completing a rejected descriptor is unsafe because AF_XDP completions are > > > > ordered: xsk_tx_completed(pool, 1) would complete the oldest outstanding > > > > descriptor, which may still be owned by hardware. Instead, leave the > > > > completion pending so the ring eventually wedges and increment the drop > > > > counter to expose the application error without risking hardware > > > > misbehavior. > > > > > > > > Document this intentional ring imbalance at the check. > > > > > > > > Signed-off-by: Stanislav Fomichev > > > > --- > > > > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > index 62de03e65a90..6a532747c039 100644 > > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > > > > @@ -2713,6 +2713,10 @@ static bool stmmac_xdp_xmit_zc(struct stmmac_priv *priv, u32 queue, u32 budget) > > > > if (priv->est && priv->est->enable && > > > > priv->est->max_sdu[queue] && > > > > xdp_desc.len > priv->est->max_sdu[queue]) { > > > > + /* Completions are ordered, so this descriptor cannot > > > > + * be completed safely. Wedge the ring to expose the > > > > + * application error instead. > > > > + */ > > > > priv->xstats.max_sdu_txq_drop[queue]++; > > > > continue; > > > > > > Hmm. I read the discussion on v2. Maybe we could cancel cq entry here in > > > this branch? Also it feels like something achievable at bind time when > > > taprio is configured and vice versa? > > > > > > Otherwise we over-commit cq entries. > > > > What do you want to achieve with the cancel here? IIUC it will make it look > > as if some (if the user has posted many) tx descriptor has not been consumed > > by the kernel? > > Oof. My bad. I meant completely different thing :D > > Right now the semantics are that we post invalid/dropped addrs to cq (the > rationale was that dropped descs are gone and unreachable which might > eventually lead to dying traffic). > > We should submit xdp_desc's addr to cq. > > Regarding the comment included in code I must disagree. CQ entries no > longer imply that 'this particular descriptor has been successfully sent > by HW'. But then we need to support some sort of out-of-order completions, no? This looks similar to https://lore.kernel.org/netdev/20260818162442.3980697-1-kuba@kernel.org/ We write desc to cq at xsk_tx_peek_desc, so when we get an error here we might have already "queued" a bunch of cq entries (which will be xsk_tx_completed(num) from sirq). So unless we rewrite the way we do completions, there is no easy way to put that desc on cq without breaking the order and racing with real completions from the HW. Am I missing something here? > > I do agree that a better idea is to probably do these checks during control > > paths, but it's a bit more involved (and not sure if it's possible? if we > > have a bunch of xsk sockets and we change that max_sdu, do we go over all > > sockets on the system somehow?). My main motivation with this patch was > > to make our LLM reviewers less chatty about preexisting issues. > > I hear you, however I feel like we do not know this driver too much and > probably we don't have a HW to test out such changes, so maybe let us try > to fix existing behavior? Let's definitely fix it properly if you have better ideas. But since we don't have HW, I'm not super confident doing anything sophisticated myself :-D