From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 7A69D95C8 for ; Tue, 2 Feb 2016 13:50:16 +0100 (CET) Received: by mail-wm0-f53.google.com with SMTP id p63so21167474wmp.1 for ; Tue, 02 Feb 2016 04:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=svX8kAXFVJ/pxO+2fpduhi5PPnkwgJktluZwCPYVpVo=; b=IBD4zL8d4xgfimnjuB/yGNfZp7dFXsNcdTW5ctAF+Gwc5GOJCu6VUnon+5ITt1ESJf S8oyapN9VJByfXTrNXZTDPW3spwJwix6xKTcgmRU7B8nabCaVTlrX0C1pu7QkahGqJ1M mIwFr2EtllBbMhmZhI+OK7sZ/0YPRn0sZoDnBtSweHkdo4mFd/u/zslEJbu/pBhIRsdR 49J+fp51Dfr/YK7gTD1B5B8TZp/67w9cXBi4Ds03KoRRkRaA4iPN6UTjPS9c2z35cnLJ ig4pv/Y0zRubnkvXjQQHFF34JnW6X5nlKa7cSNDzZlqi3vbPdgNTGLGQteXJBj14E12B p6dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=svX8kAXFVJ/pxO+2fpduhi5PPnkwgJktluZwCPYVpVo=; b=jf/xfDTt7bictplPLw041hQmh9mzSigasj1P6b3z9dNqhnDgLieb43IddHiREXbzdf nVQqK5ksYp4FasqWujvM2QCai381p0xSebI5vLh/5/8ioO2MOvDCxdiZ3y4/FnRODego /As4GhhIL87gfKQjbJcUvDeolzcpfdsejEFwdAXhg3MhhcKNV7caUPMWCWUab1qCmqyH sGuX4DKbTy/VwVOdGfnq2n9Mod3FpdnUBYds6uc8khJoqMOCUdjpWwx1RyaOwsy6Uw7c u9YPagYwmZifOj0WXBgf8EJx33C2ZFr55uQPqipDEWcDGCFTU0YIsUMQI3p6bli0mtUP lbvA== X-Gm-Message-State: AG10YOQoE7QITysPETQwF80S/n4oAaHn87mlkNWOSe/+IzbSJYKxmUKcCJfDl/EyXtaJfnm5My4p1U/GY4nt+g== MIME-Version: 1.0 X-Received: by 10.28.101.131 with SMTP id z125mr17012845wmb.60.1454417415290; Tue, 02 Feb 2016 04:50:15 -0800 (PST) Sender: castet.j@gmail.com Received: by 10.194.2.106 with HTTP; Tue, 2 Feb 2016 04:50:15 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Feb 2016 13:50:15 +0100 X-Google-Sender-Auth: A9CTg_q8_iaTlIJalgHzIimrMgs Message-ID: From: Julien Castets To: users@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-users] .hw_strip_crc weird behavior with small UDP packets X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 12:50:16 -0000 It turns out the problem comes from a Cisco bug, not from DPDK. First, I did some miscalculations, making me think the issue came from DPDK =E2=80=94 and it wasn't. > * in case 1, why data_len =3D 60 and not 56, since hw_strip_crc=3D1? And > why the CRC is present at the end? (C6 63 C2 CF) data_len is 60 because the minimal Ethernet frame size is 64 bytes and not 60, so after stripping the CRC by the hardware, the size is reduced by 4. Which is normal. The last four bytes don't correspond to the CRC though and should be 0 (explained below). > * case 2 seems totally normal: the CRC is not present Yes, that's normal > * for case 3, from what I understand, if hw_strip_crc is set to 0 the > ixgbe ddriver should remove the CRC > (http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx.c#n1399). > Why pkt len is 60 here? And why is the CRC present at the end (F5 8D > CB 7C)? Exactly the same case than case 1. data_len is normal (but here the CRC is stripped by the driver and not by the hardware), and as in case 1, the last four bytes should be 0 but aren't. > * case 4 seems ok, the CRC is absent, as it has been removed by the drive= r Yes, that's normal. The problem is my network topology: my NAT software receives traffic from a Cisco Nexus 9000 which is buggy. When the Nexus untags a packet of 64 bytes (the minimal Ethernet size), it adds an extra four bytes padding before the CRC =E2=80=94 which is expected. However, those bytes should always be zeros, but here they are random, hence my checksum issue. Sorry for the noise, --=20 Julien Castets