All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Boule <ivan.boule@6wind.com>
To: "Montorsi, Francesco" <fmontorsi@empirix.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: where to find ethernet CRC when stripping is off
Date: Thu, 21 Jan 2016 09:49:49 +0100	[thread overview]
Message-ID: <56A09BAD.5030308@6wind.com> (raw)
In-Reply-To: <ad9b0f9d05ec428c9ea922c7a28a34d4@bilemail1.empirix.com>

Hi Francesco,

On 01/20/2016 06:15 PM, Montorsi, Francesco wrote:
> Hi Ivan,
>
>
>> -----Original Message-----
>> You would be right... if the PMDs did not transparently strip the CRC in
>> software when hardware CRC stripping is disabled at port configuration (as
>> described above).
>> See for instance how the function ixgbe_recv_pkts_lro() in file
>> drivers/net/ixgbe/ixgbe_rxtx.c deals with crc_len.
>
> Yeah, I see. However, I wonder what's the utility of the hw_strip_crc feature if finally it is completely masked to the mbuf user.
> However, to my understanding, looking at that ixgbe code, I think that what I wrote before:
>
>     uint32_t crc = *(rte_pktmbuf_mtod_offset (mymbuf, uint32_t*, mymbuf->pkt_len)) ;
>
> should work, since the pkt_len and data_len has the "crc_len" removed, but the CRC itself should be there.

In most cases, yes. But not in the [rare] case where the CRC would have 
been the only data stored into the last segment of a scattered input 
packet. See how the function ixgbe_recv_pkts_lro() checks this 
particular case, and free the associated mbuf.

> I know it is kind of an hack, but at least for ixgbe that sounds like a possible (temporary) solution for me....
>
>
>> Considering your need, I think now that PMDs should keep the CRC that are
>> stored in received packets when hardware CRC stripping is disabled by the
>> application, so that the application can access it as needed.
>>
> Yes, that would be very useful.
>
>> Note that this would impose that the input packet processing of such DPDK
>> applications be aware of the CRC presence (+4 in the packet length , for
>> instance).
> Or perhaps, to maintain backward compatibility, just a flag inside the mbuf could be set that informs the user that at the end of the mbuf packet, you can find 4 bytes with the CRC.
>
>>
>> Let's see what others, if any, that might care think about such a change into
>> the CRC stripping semantics.
>
> Thanks!
> Francesco
>


-- 
Ivan Boule
6WIND Development Engineer

      reply	other threads:[~2016-01-21  8:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 15:02 where to find ethernet CRC when stripping is off Montorsi, Francesco
2016-01-20 15:49 ` Ivan Boule
2016-01-20 17:15   ` Montorsi, Francesco
2016-01-21  8:49     ` Ivan Boule [this message]

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=56A09BAD.5030308@6wind.com \
    --to=ivan.boule@6wind.com \
    --cc=dev@dpdk.org \
    --cc=fmontorsi@empirix.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.