DPDK patches and discussions
 help / color / mirror / Atom feed
From: Alexandru Nicolae <alexandru.nicolae0807@yahoo.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev]  Always get the CRC from mbuf
Date: Tue, 8 May 2018 10:50:10 +0000 (UTC)	[thread overview]
Message-ID: <80145145.1048870.1525776610305@mail.yahoo.com> (raw)
In-Reply-To: <80145145.1048870.1525776610305.ref@mail.yahoo.com>

Hello,
I saw a few discussions about CRC in the dpdk context, but none of them seem to offer a consistent solution to retrieve the CRC from a mbuf.
What I mainly need  is to know if a packet have a good/bad CRC. This 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 the 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 CRC, oversize, undersize, length error) and it will set the same error flag in the status_error field of a rx descriptor for each of these errors: IXGBE_RXDADV_ERR_RXE = 0x20000000 (/* ANY MAC ERROR */).
Moving forward, I've decided to extract the CRC from the mbuf knowing that if DEV_RX_OFFLOAD_CRC_STRIP flag isn't set, the driver will copy the CRC 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 mbufs (mbuf->buf_len), our mbuf will contain 2048 B of data and NO CRC after pkt_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 scattered input packet". I wasn't able to reproduce this corner case because of the 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 there is a way to properly configure the mbuf_pool to avoid the second issue I've exposed?
Thank you,Alex

           reply	other threads:[~2018-05-08 10:50 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <80145145.1048870.1525776610305.ref@mail.yahoo.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80145145.1048870.1525776610305@mail.yahoo.com \
    --to=alexandru.nicolae0807@yahoo.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).