[dpdk-dev] where to find ethernet CRC when stripping is off

[dpdk-dev] where to find ethernet CRC when stripping is off

[Montorsi, Francesco]

Hi all,

I need to get access to the Ethernet CRC of received packets.
To do this, I'm configuring:

port_conf.rxmode.hw_strip_crc = 0;

Now my question is: how am I supposed to access the Ethernet CRC from a DPDK mbuf? 
Is the CRC just the 4 final bytes of the packets? 

Is this correct:

   uint32_t crc = rte_pktmbuf_mtod_offset (mymbuf, uint32_t*, mymbuf->pkt_len) ;

?

Thanks,
Francesco Montorsi

Re: [dpdk-dev] where to find ethernet CRC when stripping is off

[Ivan Boule]

On 01/20/2016 04:02 PM, Montorsi, Francesco wrote:
> Hi all,
>
> I need to get access to the Ethernet CRC of received packets.
> To do this, I'm configuring:
>
> port_conf.rxmode.hw_strip_crc = 0;
>
> Now my question is: how am I supposed to access the Ethernet CRC from a DPDK mbuf?
> Is the CRC just the 4 final bytes of the packets?
>
> Is this correct:
>
>     uint32_t crc = rte_pktmbuf_mtod_offset (mymbuf, uint32_t*, mymbuf->pkt_len) ;
>
> ?
>
> Thanks,
> Francesco Montorsi
>
Hi Francesco,

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.

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.

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).

Let's see what others, if any, that might care think about such a change 
into the CRC stripping semantics.

Ivan

-- 
Ivan Boule
6WIND Development Engineer

Re: [dpdk-dev] where to find ethernet CRC when stripping is off

[Montorsi, Francesco]

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.
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

Re: [dpdk-dev] where to find ethernet CRC when stripping is off

[Ivan Boule]

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