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
