From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f68.google.com (mail-vk0-f68.google.com [209.85.213.68]) by dpdk.org (Postfix) with ESMTP id 46C42AAB3 for ; Wed, 28 Mar 2018 04:52:15 +0200 (CEST) Received: by mail-vk0-f68.google.com with SMTP id v134so554486vkd.10 for ; Tue, 27 Mar 2018 19:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2HXH1A1tVttD+hGFjSywMAzCkO3Y8gy9RgqueR/05gw=; b=HX/Ms0UK/Lc2o8NJR3UB7RtUn8QFKxhpjZCuiKjZqUO3ITx/62Bsvx+66YjG1XWsfw c9BSFaGPDwDCSx8UcYEBC6HTtJpWIqzD6ddtEQR7lZ/MfNpoOrDGmN4aNofDQ44qoeWy CLblkxfTVIkjfNJZZR4Hg/hL2idMC3OQaifl6fNcdegudFq6qFD+LxLOAS93xooF4RD1 At6aTU563AEIwFGjD4hvcGwfaWne0hEL5evvm7KJEWK+/CbVic6ENBtA6MGoYLt+C/iA QS1Ask3m5xU6zW4ufU9hLA1X1gBLBmROLRSstPf1Th1Lw4iHjTxFV//RwqUAvb+EN/+P RiQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2HXH1A1tVttD+hGFjSywMAzCkO3Y8gy9RgqueR/05gw=; b=ktmqjwEdcavvbHrgNeu9+Bs+hNVYHBr7RkXQsDzUO4+SVPjtQ/fMxK7EKabqjisnWt wczt7t4AG42CMRa3Q2Hi8VscgR0lsWzfg2kAS6zjv7Bs9He+Dl9Xn3Ufuv8vPkESM15k m2p8zqESlwrD5I23w4PtKOYHuplZiyUrFALEJ/o7lpicPr5TKFVuDcLcYU6FVaXbmaeg op0tJK9www+qaiGk/tPBNBKeg1k1h0my3qYLCA0af3gkOfp1Bz91PGVP+ba8GYkD9L20 lOse9e6Yeg92LO2cJTrUjvViiAgeJg4QPtUr08Auq50wavzrhLdAsl9wdAa91rDLqsFM FPWg== X-Gm-Message-State: AElRT7EWOlah69ehQPj+WctfP9MTZPFPEo5+330GvkjQQynJ6Axdpt0g vLcfze7+Ki1Y2faFLQ+BjoYRMMYO/upUys5peaY= X-Google-Smtp-Source: AIpwx4/BiHiQxvRRp/9IfANS8TE8U4dLO7LzrFUFfIHfaxxIo4ORHnjuGPvupPKGA6GnZXW5Hth+L8EvKRn2TBLtIN0= X-Received: by 10.31.95.8 with SMTP id t8mr1223106vkb.22.1522205534593; Tue, 27 Mar 2018 19:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.14 with HTTP; Tue, 27 Mar 2018 19:51:54 -0700 (PDT) In-Reply-To: <20180327211021.GA16677@yongseok-MBP.local> References: <20180327071434.bmkbwauak3dsbjtm@laranjeiro-vm.dev.6wind.com> <20180327211021.GA16677@yongseok-MBP.local> From: Bin Huang Date: Wed, 28 Mar 2018 10:51:54 +0800 Message-ID: To: Yongseok Koh Cc: =?UTF-8?Q?N=C3=A9lio_Laranjeiro?= , users@dpdk.org, Adrien Mazarguil Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 28 Mar 2018 02:52:15 -0000 Hi N=C3=A9lio, Yongseok, On Wed, Mar 28, 2018 at 5:12 AM, Yongseok Koh wrote: > On Tue, Mar 27, 2018 at 09:14:34AM +0200, N=C3=A9lio Laranjeiro wrote: >> 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] =3D l3_hdr_type >> * bit[4:2] =3D l4_hdr_type >> * bit[5] =3D ip_frag >> * bit[6] =3D tunneled >> * bit[7] =3D 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? I have checked other three bit fields from CQE: bit[5] =3D ip_frag bit[6] =3D tunneled bit[7] =3D outer_l3_type they are all 0 as I use non-tunneled packet. > > When I changed it to the current array-based conversion, I followed the u= se of > MLX5_CQE_RX_TCP_PACKET [1], but it looks Bin is right. A packet should be > identified as TCP packet if l4_hdr_type is 1, 3 or 4. > > Bin, will you send out a patch for it or shall I? > I'd love to see a patch from you. :-) > Sure, I will send out a patch for review. > > [1] http://dpdk.org/browse/dpdk/commit/?id=3Dea16068c00647fb6c7fe8704d8ad= 2adff6bf378f > > Thanks, > Yongseok Thanks, Bin