From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f193.google.com (mail-wr0-f193.google.com [209.85.128.193]) by dpdk.org (Postfix) with ESMTP id C8EEF1B2A0 for ; Thu, 19 Oct 2017 20:44:03 +0200 (CEST) Received: by mail-wr0-f193.google.com with SMTP id g90so9283794wrd.6 for ; Thu, 19 Oct 2017 11:44:03 -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=YWcWv5sGyZOzl/lXCtJ9zkHbchso8LnwiCC9mgj6C+A=; b=rvYhY6k6RxoWNhzGRSjq5EZEc2GDnykEQ4Nk5uRSygSmUPPebxrwQzAlu0c/VYNWh4 lOLNhWgjaSHGLfVO30sliHYwMdT11hgvYNSqT1nVfOrfei3znszaaA5wLSyxKyeeBUwm En5TLgwBmflM2cb+KNRDGHepwiJRW5XYY0OhA/w687U6bh8TV9pwJOo+poNuQ2XY2XtK MhlBEciHOl4DsyfepP5uZHiFBvP362M58soiLeAa5hKN7mpd6flvZ42Pz5sZw1hkeoGN czGhfgs5ueLPir/kw5hSz/iQ0CE0P79pE7ipLqsTBJ0txBxoXkhbg2zrEXTsGzyowgae c23A== 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=YWcWv5sGyZOzl/lXCtJ9zkHbchso8LnwiCC9mgj6C+A=; b=MZw7051f9btxV79j36d5xm3RnP+EF2+jhcn+pBmz+lsqSb4+U/Z3afQ3367BVTC2by tyny3UOQk7oIlu/Vwos+ejeOJFE+Jhi8563T4dzlHrlkOKI9eDdbyNgKk7TlfZeaqCKH b7QC43s5w+CrD8Mijs7R2j/yjpkavhyGOKl86LR2y4CACc2seddS2udRILE/rgmRHMOn 6YER29/BEO3TfEEWrOhf2AV3y96n4QDwZ/ZgAGT2R0xIHkg2q2tQEfF6bHZgL434V/gg 3InUPGzDx+ikUCOB3Gf/3dOrAPmyADKM5gcBH8dE9dG7Ga1jWB6D2Q8QElwGKIN7ocV7 OKcw== X-Gm-Message-State: AMCzsaVRYPULrucqE4tBnPhST6QVioZJc78AELQFQVDsIjjH8CsOIykW FdAKoBC/z5z/PbJ5waqsuxzilg== X-Google-Smtp-Source: ABhQp+Q2hyH/Nf8yr7a4PRsAKIikr0pyMy1o9UBJbwcjypTKcD+eUq65+H6RQhmna1D5Upjicpe3AA== X-Received: by 10.223.164.206 with SMTP id h14mr2324172wrb.25.1508438643431; Thu, 19 Oct 2017 11:44:03 -0700 (PDT) Received: from [192.168.0.109] (bzq-84-109-31-87.red.bezeqint.net. [84.109.31.87]) by smtp.gmail.com with ESMTPSA id r68sm2261266wmd.4.2017.10.19.11.44.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 11:44:02 -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> <2b3313ac-428f-aeda-5ca3-8ecf1ac1a1ee@intel.com> From: Aviad Yehezkel Message-ID: Date: Thu, 19 Oct 2017 21:44:00 +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: <2b3313ac-428f-aeda-5ca3-8ecf1ac1a1ee@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: Thu, 19 Oct 2017 18:44:04 -0000 Solved that issue, this was an issue with mlx5 PMD with the new inline ipsec code. The PMD wasn't updating mbuf->data_len correctly. Thanks! On 10/16/2017 3:03 PM, Sergio Gonzalez Monroy wrote: > 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 >> >