From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 2B0E71B1B8 for ; Mon, 16 Oct 2017 14:04:01 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2017 05:03:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,386,1503385200"; d="scan'208";a="146967081" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.252.25.241]) ([10.252.25.241]) by orsmga002.jf.intel.com with ESMTP; 16 Oct 2017 05:03:56 -0700 To: Aviad Yehezkel , dev@dpdk.org, pablo.de.lara.guarch@intel.com, aviadye@mellanox.com References: <1507987683-12315-1-git-send-email-aviadye@dev.mellanox.co.il> <1507987683-12315-9-git-send-email-aviadye@dev.mellanox.co.il> <221e06d8-c318-90a0-bd39-00f2c9666132@intel.com> Cc: borisp@mellanox.com, akhil.goyal@nxp.com, hemant.agrawal@nxp.com, radu.nicolau@intel.com, declan.doherty@intel.com, liranl@mellanox.com, nelio.laranjeiro@6wind.com, thomas@monjalon.net From: Sergio Gonzalez Monroy Message-ID: <2b3313ac-428f-aeda-5ca3-8ecf1ac1a1ee@intel.com> Date: Mon, 16 Oct 2017 13:03:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 09/11] examples/ipsec-secgw: Fixed ip length in case of transport X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2017 12:04:02 -0000 On 16/10/2017 12:44, Aviad Yehezkel wrote: > On 10/16/2017 12:43 PM, Sergio Gonzalez Monroy wrote: >> On 14/10/2017 14:28, aviadye@dev.mellanox.co.il wrote: >>> From: Aviad Yehezkel >>> >>> IP length was incorrect causing corrupted ICMP packets for example >>> >>> Signed-off-by: Aviad Yehezkel >>> --- >>> examples/ipsec-secgw/esp.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c >>> index 81ebf55..12c6f8c 100644 >>> --- a/examples/ipsec-secgw/esp.c >>> +++ b/examples/ipsec-secgw/esp.c >>> @@ -205,13 +205,13 @@ esp_inbound_post(struct rte_mbuf *m, struct >>> ipsec_sa *sa, >>> if (likely(ip->ip_v == IPVERSION)) { >>> memmove(ip4, ip, ip->ip_hl * 4); >>> ip4->ip_p = *nexthdr; >>> - ip4->ip_len = htons(rte_pktmbuf_data_len(m)); >>> + ip4->ip_len = htons(rte_pktmbuf_pkt_len(m)); >>> } else { >>> ip6 = (struct ip6_hdr *)ip4; >>> /* XXX No option headers supported */ >>> memmove(ip6, ip, sizeof(struct ip6_hdr)); >>> ip6->ip6_nxt = *nexthdr; >>> - ip6->ip6_plen = htons(rte_pktmbuf_data_len(m)); >>> + ip6->ip6_plen = htons(rte_pktmbuf_pkt_len(m)); >>> } >>> } else >>> ipip_inbound(m, sizeof(struct esp_hdr) + sa->iv_len); >> >> AFAIK the app does not support multi-segments (chain mbufs), so >> data_len should be the same as pkt_len. >> Is that not the case? >> > This is the inbound function (RX side), so mbufs are allocated by PMD. > PMD is allocating mbuf with additional 14 bytes for ETH header but > trim it before passing the mbuf. > As a result seg len is 14 bytes smaller than data len. > Sorry, I am still missing something here. rte_pktmbuf_trim updates both data_len and pkt_len, so how can they not be the same when we have a single mbuf? I think to remember using data_len instead of pkt_len so it is easy to see that the application does not support multi-segments (aka. chained mbufs) Thanks, Sergio > Thanks, > Aviad > >> Thanks, >> Sergio >