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 C6C0D42DF8; Fri, 7 Jul 2023 15:17:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 599D4406B5; Fri, 7 Jul 2023 15:17:39 +0200 (CEST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) by mails.dpdk.org (Postfix) with ESMTP id 7FE4340685 for ; Fri, 7 Jul 2023 15:17:37 +0200 (CEST) Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-440afc96271so761846137.3 for ; Fri, 07 Jul 2023 06:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688735857; x=1691327857; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=50DsPf3KWJehUCzbLHsGedS3eagI+2xAgRnF+Ta1OC8=; b=sizdIM4VtawZxf/g8R9+vg2dl52/NfZ4pvyu+NwXEhkD2l+xEri6Dd3WjYMl+/z+dh +TIWt0H97QYBxbJm3ncLF0pxGef8mWrxnFiTWcrhPOW1LHxuedh/qoVzh4Js2lla7TgJ QSJ5Rzfc/3WYQ1atWAbtRsnBh2tMyTCE3+gJ+X7vQwOUmlEievjZXIMPmJ9+OJpQSbWV jk20BrV0pCjUA3wFiOy015MqpPfvJzbkEjAD0P+n+Dx9fbEIyU8l3ihxtliS+s8GY4Ft oAJHTzJLo986JmgrNQzlxU0h+72Vvmidxi5PNijtMzDAQK9V9lkXVJXK6PRb81q9/Ywh ej1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688735857; x=1691327857; h=content-transfer-encoding:cc: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=50DsPf3KWJehUCzbLHsGedS3eagI+2xAgRnF+Ta1OC8=; b=AlAe9xUa15mKujNu/ToZqiTmjeNDTY4jppkI/A4k6g7kXVOSXeBTYuTBRXULAuQZsV pmI8AaGUJYmaizqUQV6gwfz+OfV1aVZ4TlUnaf330Yntt2hI5fiEzQqQRBmk8+FtQSrW comXyXGaws1IoJnXy/NtAtDNgn1pXJx4Sfurcl+ocvLmCzyO9CnfjUMk6zNWHAdd0nuJ bMz4H2zkJ4/v32QyDvg1WH1PcLmzn0bwmEIEyAZZI3311S5SLojz/lBBDIqgCTeM9LEs sfmtLBbf4dO9qnsrMvqA6M1jXL+Ry6Q4aDsVqScJyfuTGruqUF9VMtaSi7JCEyXtUU7V fohw== X-Gm-Message-State: ABy/qLajvUXE/y4vsqGanpMI+jxa7ZyyisStduUvbPSD44AY0ENs7lp/ 29aknEItMmc06TMon622qWgzVoElDWtAFz7WTj0= X-Google-Smtp-Source: APBJJlHNL6PfhoX7Fntr2/VyNpF08Z3NDhryMBY8DDZ3lqjA1RSTdOja1W7OlsCaYSlZsrNZvzec+0Z+K+G5AAeXerQ= X-Received: by 2002:a67:ce89:0:b0:443:7b05:ab23 with SMTP id c9-20020a67ce89000000b004437b05ab23mr3753218vse.20.1688735856800; Fri, 07 Jul 2023 06:17:36 -0700 (PDT) MIME-Version: 1.0 References: <20230418084613.52740-1-shaw.leon@gmail.com> <05b87294-0b96-804c-f4e7-0fc3b3ccbbf4@intel.com> In-Reply-To: From: Xiao Liang Date: Fri, 7 Jul 2023 21:17:00 +0800 Message-ID: Subject: Re: [EXT] [PATCH] ipsec: fix NAT-T length calculation To: Radu Nicolau Cc: Konstantin Ananyev , Akhil Goyal , Konstantin Ananyev , Vladimir Medvedkin , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 The context hlen =3D sa->hdr_len + sa->iv_len + sizeof(*esph); ... ph =3D rte_pktmbuf_prepend(mb, hlen - l2len); ... update_tun_outb_l3hdr(sa, ph + sa->hdr_l3_off, ph + hlen, mb->pkt_len - sqh_len, sa->hdr_l3_off, sqn_low16(sqc)); assumes L2 header length included in sa->hdr_len. Even if hdr_len doesn't include L2, then mb->pkt_len won't either, so UDP datagram length should still be mb->pkt_len - sqh_len - sa->hdr_len + sizeof(struct rte_udp_hdr); On Fri, Jul 7, 2023 at 8:51=E2=80=AFPM Xiao Liang wro= te: > > > sa->hdr_len and prm->tun.hdr_len don't include L2 length so both should > > start in the diagram at the end of the ETH header. > > > > So the right way to compute datagram length is > > > > dgram_len =3D mb->pkt_len - sqh_len - sa->hdr_l3_off - sa->hdr_len + > > sizeof(struct rte_udp_hdr) > > > > |<- mb->pkt_len - sqh_len ->| > |<- sa->hdr_l3_off ->|<- sa->hdr_len ->| > |<- udph->dgram_len ->| > > +--------------------+------------+-----+-----+---------+-----+ > | ETH | IP | UDP | ESP | payload | sqh | > +--------------------+------------+-----+-----+---------+-----+ > > |<- sa->hdr_l3_off ->|<- l3_len ->| > |<- sa->hdr_len ->| > > If hdr_len doesn't include L2 length, I would agree that > > dgram_len =3D mb->pkt_len - sqh_len - sa->hdr_l3_off - sa->hdr_len + > sizeof(struct rte_udp_hdr) > > But then what's the point of > sa->hdr_len - sa->hdr_l3_off > in lib/ipsec/sa.c?