From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.219.51 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794481433; b=jUPY3SPSWTojTsfmPVoX0Y3lQO8l4pa7x/eyBFiGshEpPUWAhMj1oq3BfY6vYrwY3sXd zcYGguz/fc/FEM8dpwCNZm7NLRzRDZrxZLJpQAcr8lHtheyrNG8mvV1gn93+SMRn/vmjy vv17oQHTeQyqRieV6fejglTthAy2aTDdu4G6raOWmNQtAHYx4mFbpAyEn1qAi3p+jROxs 2Oit0+xRxZObo8KOe3/8U0ZzKdTpCLTJTsF7e+lvMH5Rv1r0d1qrOR6qclwNevvexUaOe AcrH0aqL9ACjEQSx83gRKoDX+CshHsp5iuD0i0WmWxrW79KCbMVNPiLlvZ0S87pfn9Q== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794481433; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Mime-Version:Content-Transfer-Encoding:Content-Type:Date:Message-Id: Subject:From:To:Cc:X-Mailer:References:In-Reply-To; bh=7DL6NZ+BkMPV7VqBQUXBvWcIZ0TJ2DQpusktaObjwcA=; b=35I+y7I1KdjHHoS1r9pLbAmjfNz/+Zxw6ot5R4UywoWCco9yQxZ+z/XwboBcFKT3f74x WGOGqf6suBijLDxt9EoWmi9Y681SwEPT92UoV/qMEnQOh8CPyG+JzEe/Dvlrk/w1He3xT aHCotjRrj9v+7ABe3MKr70uQ7ezxqE7Uvmmff6lL0g7N7VPxVMZiQd+tbTVsZv1yeXrif AU9a8/V/OC3TXxZEZ9Jg/WlrnbKjOCcwhq7lVhYEprE0OlHhJhTb7v2962YBmIhl8l9oc WAwsEFJJ0vv8uuyqSdknCM+mXCx9oS7e6FoZogj6rNtE8EA71gUnKTHA0n6TMMyu67Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=bTHF5xOZ; arc=none smtp.remote-ip=209.85.219.51 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 223B4606A31C for ; Thu, 12 Nov 2026 11:03:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 223B4606A31C 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.a=rsa-sha256 header.s=20260707 header.b=bTHF5xOZ Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-91ea5600c9cso11107216d6.1 for ; Thu, 12 Nov 2026 03:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794481432; x=1795086232; darn=vger.kernel.org; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=7DL6NZ+BkMPV7VqBQUXBvWcIZ0TJ2DQpusktaObjwcA=; b=bTHF5xOZC5ct22O4VSF5DGZdCzLfPtQcvnyeZBW5YGxHf4Hu9NvdPMpmXwL3e1UF43 7sIULqSy3m5xcOCehqDMQDBgzENiQoJpHkIhlyB9xr+sdCKc47ktGru5X8g0i7SXTng/ 7fM7WSEl56hr3jeCEOAcbZ5Eds1lD9KL4Qs+5Ukw3UFYzLM1M3viUjZQiunDbrrjT2t3 8uGN8vdiURQ111vP+2qfGvI9TTzoG9LE+OP8877Mbg/jvni1oLAVVZ6SfJ10LkMALIuM nn3ZGR4T3iOSyOa2qq9UN2UIvj1TORTEZpO6s0gnn7ZcgF8Zg6XcvDyC0njkUJcJehlV Frow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794481432; x=1795086232; h=in-reply-to:references:cc:to:from:subject:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=7DL6NZ+BkMPV7VqBQUXBvWcIZ0TJ2DQpusktaObjwcA=; b=ESJFJPGG3B8hgiev+gDFuQw8wcxZPnM4jiUqciOZv026HLAAzZ9dEhkulsfZzruVLW n5qNmuxC3IRNAbOqSa5/wMfy7IhndjW/FX2xtd5q0bB2o8UIloLaHpmHDIT9fSO/RJuo rwrrxzSMH0mjrxiHqY9KcRHYtQGZKphewLZm5G+x7k78z5RG2zpvrPhEyc9vOKMEwqrM tbtW2k+lL0G8l0tkglSs/cXR4FZsdwmEjkaU70DN4BIOL7OL3a3Kum93w5IduihLcgYR 3qi9OPUfWyhbVJ/Hp837v+jxxQ0uUqznzlPDzcbnzuEprrZjipxMTmxk0FnQsIrLw+ji k0eA== X-Forwarded-Encrypted: i=1; AL+hErGP1t8e2IRkwIeU1qvg8EfJzvQfYUl1T3QIJzwGXuyoo3kI32op+HksoW/mXqJPpW0b/AVuGiFdmyCjJZg=@vger.kernel.org X-Gm-Message-State: APuU4Z9TALx/HreGBLB0/0GcNThDxnx9FU+apJFr25GEV3NAQPxGEgaM 4kjx94YrFht1afjJhfmiejo4XR71hIvUmVMoVjWsxRFUTKMsFT84spKjcnp+gg== X-Gm-Gg: AYBFou0T14TBg/VwBFtgoc5i0bcWDni+q9XZ9tMdJ0lABPxXOAQFUE5SlIP+fIYn8cw 1Ji1WnEzq2BnBfgCEwHUgG46LnpejSxGobWQb0ahzvygL6fT/LZIomDvUTH1Twde7NCCNgNUqdZ 1zzCO75Xou2p/yy/TQgKH/Rz+dk1oaQLePfQun/ENLwcnkPVpmRufTRBmoT7lEH3TklDMu4lBMs iZQAytfWHvOzSB4GsC0z8qpwEDoic6R0Koj4oPitgCwXpFDKgFSpbfbHIZ5krZUBQu7cB9OfMMt HG4hud+pwh7dNo/j+BXuW7vS/VpIB2QSWZJAyoPE+SnD/lCYaPZNrp4drNVpOVKw9DFEp5JTCWb yIP1FoPzpe8ZVut+O3iZXm1PyQ31NZ3nf+eNxfupeSRSNOIzY9OKWmF/8bUmWSccgOYnKtZGlp9 IiNjT/hGBGrZi47Nj3JK1I0NlBJDex+G5/pKoyqdPa+Cw04aqFVG0BfyBx1Vvps2CGYNaZLyOyn y5cLicOuDX8rpFxhW2FYDp7AJwwM2evKpf76sCUoZfiBFjX+YJy+0nUAln7uvvZJC3ferfy83Va zjx4T3PhQeNCfUlB8hjZrwX2VtPZlrMGw6w= X-Received: by 2002:a05:6214:5291:b0:91f:1bd3:d98a with SMTP id 6a1803df08f44-91f1bd3f546mr9764396d6.6.1794481432126; Thu, 12 Nov 2026 03:03:52 -0800 (PST) Received: from localhost ([2600:4040:9399:4000:e553:72e5:7d37:c7ef]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-91f20176493sm1379066d6.5.2026.11.12.03.03.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2026 03:03:51 -0800 (PST) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 12 Nov 2026 06:03:50 -0500 Message-Id: Subject: Re: [PATCH net-next v2 4/6] eth: mpnic: UDP segmentation offload From: "Daniel Zahka" To: , Cc: , , , , , , , , , , X-Mailer: aerc 0.21.0-threadmapfix References: <20261110-mpnic-lso-v2-4-ccd37b051d08@gmail.com> <179447813712.2199510.12165491734923049464@kernel.org> In-Reply-To: <179447813712.2199510.12165491734923049464@kernel.org> On Thu Nov 12, 2026 at 5:08 AM EST, netdev-bot+sashiko wrote: > Thank you for your contribution! Sashiko AI review found 1 potential > issue(s) to consider. > > Critical: 0 =C2=B7 High: 0 =C2=B7 Medium: 1 =C2=B7 Low: 0 > > If you believe none of the issues are legitimate, please reply to each > issue of Medium severity or higher and explain why the AI is wrong. > If any of them are legitimate and you plan to respin, please let patchwor= k > know by including "pw-bot: cr" as a separate line at the end of your repl= y > (one such reply per series is enough). > > - [Medium] This patch adds `skb->len < MPNIC_MIN_FRAME_LEN ||` to the > generic `skb_is_gso(skb)` branch of mpnic_features_check()=E2=80=A6 > > -- > > eth: mpnic: UDP segmentation offload > > This commit adds NETIF_F_GSO_UDP_L4 support for non-encapsulated udp4 > and udp6 packets. As for TCP, the UDP checksum is seeded with a zero > length. It also makes mpnic_features_check() fall back to software GSO > for skbs shorter than MPNIC_MIN_FRAME_LEN. > >> diff --git a/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c b/drivers/net/= ethernet/meta/mpnic/mpnic_txrx.c >> index b78f8599bbe8f..2a0560b7dd19e 100644 >> --- a/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c >> +++ b/drivers/net/ethernet/meta/mpnic/mpnic_txrx.c > > [ ... ] > >> @@ -369,7 +384,8 @@ netdev_features_t mpnic_features_check(struct sk_buf= f *skb, >> return features & ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK); >> =20 >> if (skb_is_gso(skb) && >> - !FIELD_FIT(MPNIC_TWD_MSS, skb_shinfo(skb)->gso_size)) >> + (skb->len < MPNIC_MIN_FRAME_LEN || >> + !FIELD_FIT(MPNIC_TWD_MSS, skb_shinfo(skb)->gso_size))) >> return features & ~NETIF_F_GSO_MASK; > > [Severity: Medium] > This check applies to every GSO type. That means TCP GSO skbs shorter > than 60 bytes now fall back to software GSO too, not just UDP ones. > > The commit message body only talks about UDP. The only mention of this > check is the v2 changelog below the "---", and that text is dropped when > the patch is applied: > > v2: > - fall back to SW GSO for skbs shorter than MPNIC_MIN_FRAME_LEN, since > HW LSO would segment the zero padding as payload > > Should the commit message describe the effect on TCP? Or should the > check move into the earlier "eth: mpnic: TCP segmentation offload" > patch? > > With only the TSO patch applied, TCP seems to have the same problem. In > that version, mpnic_features_check() rejected GSO only when gso_size > didn't fit MPNIC_TWD_MSS. So a short TCP GSO skb reaches > mpnic_xmit_frame_ring() with HW TSO enabled, and gets padded first: > > drivers/net/ethernet/meta/mpnic/mpnic_txrx.c:mpnic_xmit_frame_ring() { > ... > if (skb_put_padto(skb, MPNIC_MIN_FRAME_LEN)) > goto err_drop; > ... > } > > Then mpnic_tx_lso() seeds the TCP pseudo-checksum from the padded > length: > > payload_len =3D cpu_to_be16(skb->len - skb_checksum_start_offset(skb)); > csum_replace_by_diff(&tcph->check, (__force __wsum)payload_len); > > Locally generated TCP GSO skbs are always longer than 60 bytes. A GSO > skb built from a virtio_net_hdr can be shorter, though. Sources include > tun/vhost and packet sockets with a vnet header. Such an skb can carry > a tiny gso_size and only a few bytes of payload. > Local sashiko review surfaced the same complaint and wanted me to pull the check forward one commit. I decided against it. The UDP case is easily reachable because the user chooses the gso size. I don't think producing a TSO skb shorter than 60B is really possible. The virtio_net_hdr cases should have a min GSO size of TCP_MIN_GSO_SIZE set in virtio_net_hdr_to_skb(). > In that case, wouldn't the receiver get the zero padding as TCP stream > data, with a valid checksum? > > The check is still present at the end of the series, so the final tree > is fine. The TSO commit on its own would still corrupt data if someone > bisects to it or backports it alone.