From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Boule Subject: Re: where to find ethernet CRC when stripping is off Date: Thu, 21 Jan 2016 09:49:49 +0100 Message-ID: <56A09BAD.5030308@6wind.com> References: <30b91c74ca26434daac041713cffa153@bilemail1.empirix.com> <569FAC72.3090001@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: "Montorsi, Francesco" , "dev@dpdk.org" Return-path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 02CF38E84 for ; Thu, 21 Jan 2016 09:50:07 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id u188so216618047wmu.1 for ; Thu, 21 Jan 2016 00:50:07 -0800 (PST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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