From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 42D5EA0544; Tue, 11 Oct 2022 07:48:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E14AA42BAC; Tue, 11 Oct 2022 07:48:11 +0200 (CEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by mails.dpdk.org (Postfix) with ESMTP id 223FC40F19 for ; Tue, 11 Oct 2022 07:48:11 +0200 (CEST) Received: by mail-vs1-f50.google.com with SMTP id h3so5429193vsa.4 for ; Mon, 10 Oct 2022 22:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=dN433dfwrc/Q6mA518WygEQHwdcmgDLgruhHwyjd/2A=; b=ZScdoxicUlHXtXHp7/0e5uzGT1z5dkFO8KWhaNCnVuaKnTXVAzeL0K6aq9qzYYOW16 5EUEv0IjnuReZbk/pV1TzdR6V95OzeOvTue5Ik9JeJpWIET2CrT+ncJNY64SS4cpGoM6 MftG9xporouNs+P4XoQEjWG+5ymuXR2BFnsjWd2SdL0w5uKbnRsKsZLPJg9okh/oe6nF 5X1LvY9higacgt3chiMIbhH6fTzKa3GOgyaHcu0SryrVI9nC1OSFeTtaq+xpCaSJWxSU RAV2T96986pgVBhcB15CzRk624B7l0Se6wM4qNqnO00w+Ch+ZQSTgpPN4pzmcBtoGw0v SjjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dN433dfwrc/Q6mA518WygEQHwdcmgDLgruhHwyjd/2A=; b=5Km61B3sMEU6TqI7w1weakml9VNB3CkEYQlTnHFUPSS7YHKP+VO93bUOpJH8lHHEL1 Y9SDTDrXKznPytUOBBGc2F3PFvBrRy+NOBNpXY4tUzCmugdGcUYZ3ue/Cbf6O8XUs5Dk R4FpeKLxNnrERBrSAX/y74oW/C0TVa7XS3aQE+v/ATpp5R7GTLcKXjxKnUj9muhKztG6 w/EyHN2yWbVRunBOOvQcblFJBGyMFZ/mx0+LcLt2k0HaXHSaUv3MhlJ3JYfDkVNxG2DG p8Zs6zIvO5dW5Yxaw/mkX7mtIHxy6UIbbGlt3B4i+WN0k5r3mAm050kVM8AitF7b5qhb 1ROg== X-Gm-Message-State: ACrzQf2HG1/zM3wf+3twk+6TkN5b+5Wb4an+m5bCKqgNuSQxrxev4uGS DMx4CXmJFuk7P1yNV8TbDOsrFw3k+GTXze2idQSp3D8EbJg= X-Google-Smtp-Source: AMsMyM6RZx3rFk3JvF1/Ul2CH9morObpGZfYLFbN/rrmA4/qQxQqgqM088LcFu1+rjwBpjU4bWHDj8mzmRaFo8gGXNk= X-Received: by 2002:a67:a246:0:b0:398:a4f4:aed1 with SMTP id t6-20020a67a246000000b00398a4f4aed1mr10939515vsh.6.1665467289882; Mon, 10 Oct 2022 22:48:09 -0700 (PDT) MIME-Version: 1.0 References: <20221010175109.44282-1-kumaraparmesh92@gmail.com> In-Reply-To: From: kumaraparameshwaran rathinavel Date: Tue, 11 Oct 2022 11:17:58 +0530 Message-ID: Subject: Fwd: [PATCH] gro : fix pkt length when extra bytes are padded to ethernet frame To: dev@dpdk.org, David Marchand , "Hu, Jiayu" , Jun Qiu Content-Type: multipart/alternative; boundary="00000000000032d5c805eabbd21f" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --00000000000032d5c805eabbd21f Content-Type: text/plain; charset="UTF-8" On Tue, Oct 11, 2022 at 1:03 AM David Marchand wrote: > On Mon, Oct 10, 2022 at 7:51 PM Kumara Parameshwaran > wrote: > > > > From: Kumara Parameshwaran > > > > When GRO packets are merged the packet length is used while > > merging the adjacent packets. If the padded bytes are accounted > > we would end up acking unsent TCP segments. > > > > Signed-off-by: Kumara Parameshwaran > > v1: > > If there is padding to the ethernet frame cases where timestamp > is disabled > > the packet length should be validated with the total ip length > as packet length > > is used in the GRO merging logic > > Please, can you test with current main branch? > We recently merged a fix: > > https://git.dpdk.org/dpdk/commit/?id=b8a55871d5af6f5b8694b1cb5eacbc629734e403 > > Thanks, David. I did look at the patch. This would fix the problem, but >> lets say for a case of an ACK packet where TCP data length would be zero >> and if the packet contains the padded bytes, this check should be done >> before the follwing check and not after this. @Hu, Jiayu >> @Jun Qiu please let me >> know your thoughts. >> > /* >> * Don't process the packet whose payload length is less than or >> * equal to 0. >> */ >> tcp_dl = pkt->pkt_len - hdr_len; >> if (tcp_dl <= 0) >> return -1; >> > -- > David Marchand > > --00000000000032d5c805eabbd21f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 11, = 2022 at 1:03 AM David Marchand <david.marchand@redhat.com> wrote:
On Mon, Oct 10, 2022 at 7:5= 1 PM Kumara Parameshwaran
<kumarap= aramesh92@gmail.com> wrote:
>
> From: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
>
> When GRO packets are merged the packet length is used while
> merging the adjacent packets. If the padded bytes are accounted
> we would end up acking unsent TCP segments.
>
> Signed-off-by: Kumara Parameshwaran <kumaraparamesh92@gmail.com>
> v1:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If there is padding to the ethernet f= rame cases where timestamp is disabled
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the packet length should be validated= with the total ip length as packet length
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is used in the GRO merging logic

Please, can you test with current main branch?
We recently merged a fix:
https://git.dpdk.org/= dpdk/commit/?id=3Db8a55871d5af6f5b8694b1cb5eacbc629734e403

Thanks, David. I did = look at the patch. This would fix the problem, but lets say for a case of a= n ACK packet where TCP data length would be zero and if the packet contains= the padded bytes, this check should be done before the follwing check and = not after this. @Hu, Jia= yu=C2=A0 @Jun Q= iu=C2=A0 please let me know your thoughts.=C2=A0
/*
* Don't process the packet who= se payload length is less than or
* equal to 0.
*/
tcp_dl =3D= pkt->pkt_len - hdr_len;
if (tcp_dl <=3D 0)
return -1;=C2=A0=
--
David Marchand

--00000000000032d5c805eabbd21f--