From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 9DA971B6A5 for ; Mon, 16 Oct 2017 13:44:39 +0200 (CEST) Received: by mail-wm0-f67.google.com with SMTP id f4so2352575wme.0 for ; Mon, 16 Oct 2017 04:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dev-mellanox-co-il.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KgtwmCee1vjZbEDeWgjpdtTO513FrGB5bZLPT2JvIkE=; b=u4dXrVECtXl3IynwyUwbikeLjSGm6hmhf6HBvbiLkLzYZDCQPspsWVyjLPUa/dqZ43 P1h6oLe5IrB/sOUc6guoo3yMUTfXQjWuYPkmtIDFnBw05E/e2Hy6814Pcsamq/JrPWe0 qwrt7jLQINo2ostAqg5h5DEsdZEBI0ghaC3um6oJzEhjt9qiH/Wykbh8zW2p+wP6kHni TdAwTwuojais+wabLvzpvWJ0u/d74s1li4SvQumkgsl92tFiUAfAnkA6YbDqXmgsCVAF zeLwp2nppPZ9nVkci71GfUWhIx4cFn+zvdwKbrbGO7WbVGJbNn/xSGRMG68Y9lcClBuB Rmvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KgtwmCee1vjZbEDeWgjpdtTO513FrGB5bZLPT2JvIkE=; b=Wy+0UmiaD5TTG98D8ZTZlgwQxZeMoekAKFa36ctwxyLJqWNBi1ovYfL6D6H/3s0RtU jeXtqCrvM/yAM9mUBZCKKLXmj46Y5qrVZesYnN2fXw8fcTe5cKsZHf7iZWmnfcrMueKp RZfgQrLBmEW1ZTqdXOutYsj7ahB3Rfu9Jm7eZEDTh1mh7Xs0yw4ypjpBr1hf+HdtCqlE tFxFOVAmi2AaH4eiq0/cwfj6HMLm7uTiQAiIjdGOqb4u1rgLC6f8nGWc0DsYzf6Tq1AM eCFSgZnOfg6Nb48CL6PTOZQrJKEj/ka4VnKRUi0K/OXry01fPIPs4+b1AypMKiALhqNa VjGA== X-Gm-Message-State: AMCzsaW9e/7C9pEslhxk+t0KfV+HGnghwVnHvxIeJPAhevFXlHTdWFI6 LbFZwjClIFRuZHzwfaQ3q0MU+Q== X-Google-Smtp-Source: ABhQp+QhnelCcggbg6KcSl1SOiOhHQ1zg8v3JL2oDdwTzZIN3rEspxphiHsMs/gAtBf1RVDIvsdq2A== X-Received: by 10.223.195.110 with SMTP id e43mr283755wrg.219.1508154279315; Mon, 16 Oct 2017 04:44:39 -0700 (PDT) Received: from [10.0.38.219] ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id w82sm13424150wme.5.2017.10.16.04.44.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 04:44:38 -0700 (PDT) To: Sergio Gonzalez Monroy , dev@dpdk.org, pablo.de.lara.guarch@intel.com, aviadye@mellanox.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 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> From: Aviad Yehezkel Message-ID: Date: Mon, 16 Oct 2017 14:44:36 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <221e06d8-c318-90a0-bd39-00f2c9666132@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 11:44:39 -0000 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. Thanks, Aviad > Thanks, > Sergio