From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id 34C295F1D for ; Tue, 27 Mar 2018 09:16:00 +0200 (CEST) Received: by mail-wr0-f171.google.com with SMTP id o8so21244126wra.1 for ; Tue, 27 Mar 2018 00:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=5NmWJU4d8E/Qe3plcn16A4EUuWfyBMlEAjSYRXbmA6s=; b=cjSMRHrumpB6fK7C/cvzMIStKuCXCfNl3UKqd7kuZ0ffodE6ZCkgeK3nokBHdBjX0E UI8JV3V/jb10vLQOK6NwTdy5+hWyc0sBN2EqkG12Wik7o86V6tWUlqF6NNZsIg/yp4WL IrGIm1H13yFGJ6iYALfXQ2igeAQy27e6vdoi024PgrVLAQ5gUVlGWdS9CL9dmu/nOEVo oXvdWXEMozPmu58htH5TFmcPZ8cr8ZLfEEFyjF8KcBrWcFownLjDi9/lQaMczJnp+JPE UFhCeR8FbHLSHZhr/04+3CTZphL+uSG8iAcvcnfmPRbIWsSbhrMI0rfZWEY7BWPWnFtX B09w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5NmWJU4d8E/Qe3plcn16A4EUuWfyBMlEAjSYRXbmA6s=; b=juGpIVymE4/6KXuWy8vwAehqCzgjIVckw4lRemgKdPPhTX8baXreNnbjf5Y2PmtAtB Sv1KAtaOFy31LrvvldNFp5SmC7E5+VIYOElr1+MvQtJyB2f6Oa9KISYomtVfimX+Lwey XBaz4lEzaYlf0hkp4crZEeCNGF6P6DsDHL+ixwiY0FG9kUDd2cxHaHfIF6uL3W7mQdt+ Tv1DlYo+FOBHfoi89Uj7B6LdvUhycRubitgwSYgBr3e1Y3lJzbOgLzhtgdhZipaG4CrP UHaMncEJrO+AusrbYdmXBx/Ui1onrows+4tyZazxsR8W64HRRawyjoSHXETtZEssN4Qf iwCg== X-Gm-Message-State: AElRT7HRw+Vdq/ngeDiKznIv3hi9xH+EP/HVS3ahJHcDc0bRWNcl/CH9 JXZYKWW/Kcgj8Bny1IqGGqeD X-Google-Smtp-Source: AG47ELs09BAc2AteJSwRNb8saTxNYaUDmoIJUns3Wk8gRKE2vrtpbZb5hEL8St3e3vVzddeXzgUTwQ== X-Received: by 10.223.149.68 with SMTP id 62mr14302140wrs.201.1522134958705; Tue, 27 Mar 2018 00:15:58 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id b38sm1204922wrg.81.2018.03.27.00.15.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Mar 2018 00:15:58 -0700 (PDT) Date: Tue, 27 Mar 2018 09:14:34 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Bin Huang Cc: users@dpdk.org, Yongseok Koh , Adrien Mazarguil Message-ID: <20180327071434.bmkbwauak3dsbjtm@laranjeiro-vm.dev.6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-users] mlx5 driver didn't set corresponding packet_type flag in TCP_ACK packet case X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 07:16:00 -0000 Hi Bin, On Mon, Mar 26, 2018 at 06:09:35PM +0800, Bin Huang wrote: > Greetings all, > > > I have run l3fwd example program using two mlx5 NIC( > MLNX_OFED_LINUX-4.3-1.0.1.0 ) base on DPDK 17.08 and use pktgen as > flowgen. > > This demo provided by DPDK works fine in UDP case, but in pktgen TCP > case, l3fwd can't forward packet to nexthop port. > > > After look into function rxq_cq_to_pkt_type(), I found while handling > IPv4 TCP ACK packets: > > > l4_hdr_type bits[2:0] in CQE is (100) > > > l3_hdr_type bits[1:0] in CQE is (10) > > > It looks fine according to CQE format in > doc: > > > l4_hdr_type: > 0 - None > 1 - TCP header was present in the packet > 2 - UDP header was present in the packet > 3 - TCP header was present in the packet with Empty TCP ACK > indication. (TCP packet flag is set, and packet carries no data) > 4 - TCP header was present in the packet with TCP ACK indication. > (TCP packet flag is set, and packet carries data). > > > l3_hdr_type: > > 00 - None > 01 - IPv6 > 10 - IPv4 > > > But combined l4_hdr_type and l3_hdr_type into idx, the idx would be > 0x12, which was not reserved in mlx5_set_ptype_type(). > > Then RTE_PTYPE_UNKNOWN would be return to caller which caused > sub-sequence procedure going wrong. > > > Did I omit any possible configuration to make ptype flag work for TCP > ACK packets, or should I add (*p)[0x12] in mlx5_set_ptype_type() to > make this work? According to the mlx5_set_ptype_table(), the index of the array is a little more complex: /* * The index to the array should have: * bit[1:0] = l3_hdr_type * bit[4:2] = l4_hdr_type * bit[5] = ip_frag * bit[6] = tunneled * bit[7] = outer_l3_type */ If in the CQE the other three fields are 0, your hypothesis is correct and index 0x12 should be filled. Can you also check it? > Thanks for your time, > > Bin Thanks, -- Nélio Laranjeiro 6WIND