From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) by dpdk.org (Postfix) with ESMTP id B42CF7CCA for ; Tue, 8 May 2018 12:50:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1525776615; bh=qUxCRGGXyHvK4+wfs8s8MztPM6KBThGtGvNXe2MdO74=; h=Date:From:To:Subject:References:From:Subject; b=N3vH/bngddIADJANhhgPQfqTsZ/IU5DrtkKWVVLyRt20aoJR9tln67eoiBYLEcChr1HyR4GODrw87B6bp6M0I9hMEngSQVplnw57yQU3e+UAu9/+A1KWSeDsdfJL3zLNtK8/0vryLiDl5Bf8jfd71gGhGvAmtdRfIW4zpaR4vuiN4SsD8eVEtbtL81SfWb/PC8ogWjEG3mH5phMOl9ygIJlB+sObHyVSQYJTPgyV8GRIB3mtUQe55QlyQvqMH5jbQWQDsWsx0jtcIClg3MrMHXhYsw9ZMiHpZXpCXf72l7D9Tor97+wJKStdtAhy0eBaSiCns+M4SwEAKOf+QEj6vw== X-YMail-OSG: 6PezzTwVM1nLScgPVarOAxX1eQfTcCxV8vRUmZmE5hdc9xc7lpd3KZ0W_ZMKPte 1TE0idFussPwP74hQbklhhczPZLQ9mGYmrDJ_zD.0fHTD0OluY4wZAByoIQDHTeTKFWp1uVetgRG UsRK4THSqepNyVCTTEWPB4ocIxeCILaDTOzyu2com8TemxQIUrFuzp9T0z9tqkH7CmMjIKxP3B.A 7lQkG_PRLF1euA61a2KfKKP6g2JRWlY2Awzbq1tZcG9ZmM_V_9g.dewrfxrudl0d.OotR5DKXNGg jrjl9cpaBSXwnMuJPRweJGCO06YfBnqYYpoxPAx9iUjZkSvd4n.WaHUOb5jglZGv6tnRKTne45VZ 0nG_ieVh7G7eIz_C5ArWLuV3rCwuon9TVZNie2_aYla1mmrHl6jBVOrrHkovI2tDrFtBzdtf2RJn puN5awoPqdTulXNk.y51Lu1aWfYCJtAxr.i.OwIcArtciyfFLRKu98u8aIKFshR9EphJsZMd.0zM qRae8gtlE_mmLtUYeHF6cMRzxudXadKJrL1thZZXkOrF5_YETD23JYltITQhSDRXP.0dxBeMHSlR nOv4bU3mVWYRiI8XuOnQZ1zesU8U- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 8 May 2018 10:50:15 +0000 Date: Tue, 8 May 2018 10:50:10 +0000 (UTC) From: Alexandru Nicolae To: "dev@dpdk.org" Message-ID: <80145145.1048870.1525776610305@mail.yahoo.com> MIME-Version: 1.0 References: <80145145.1048870.1525776610305.ref@mail.yahoo.com> X-Mailer: WebService/1.1.11848 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Always get the CRC from mbuf 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: Tue, 08 May 2018 10:50:16 -0000 Hello, I saw a few discussions about CRC in the dpdk context, but none of them see= m to offer a consistent solution to retrieve the CRC from a mbuf. What I mainly=C2=A0need=C2=A0 is to know if a packet have a good/bad CRC. T= his would be easy if there would be a flag in the mbuf structure to signal = this. Having this in mind, I tried to propagate this information from driver to t= he mbuf by creating such a flag, but it seems that (for ixgbe at least) the= driver doesn't make the difference between different packet errors (bad CR= C, oversize, undersize, length error) and it will set the same error flag i= n the status_error field of a rx descriptor for each of these errors:=C2=A0= IXGBE_RXDADV_ERR_RXE =3D=C2=A00x20000000 (/* ANY MAC ERROR */). Moving forward, I've decided to extract the CRC from the mbuf knowing that = if=C2=A0DEV_RX_OFFLOAD_CRC_STRIP flag isn't set, the driver will copy the C= RC in the mbuf after mbuf->pkt_len. This seems to work well in some cases, but there are certain scenarios when= the CRC isn't copied at the end of the mbuf. For example, if we receive a = 2052 packet (including CRC) and the mbuf pool is configured with 3000B mbuf= s (mbuf->buf_len), our mbuf will contain 2048 B of data and NO CRC after pk= t_len. Also, someone stated previously that we can hit "the [rare] case where the = CRC would have been the only data stored into the last segment of a scatter= ed input packet". I wasn't able to reproduce this corner case because of th= e previous behavior: the CRC isn't copied at all in the last segment. Do you guys know if there is a best practice to extract the CRC? Or if ther= e is a way to properly configure the mbuf_pool to avoid the second issue I'= ve exposed? Thank you,Alex