From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=UTzxxGzQPCGUTVrSvpxZdKn9viuOCJYpCiAl/PfwtPw=; b=R0QHS8ANfljo/f1d3M5lN8i9Ve1fUrooOIF/cs0JJ4+L/gPv3phXmXmcybGYD3tELh ++TSGaztN6mlfWVAQDkzGZmGxEKE4cOFcCA5fRpL0ZjV7P5+0i599lZpioOqAKDF2yal gAbrFVvSLkDOHOlfGFVUDqI/GtQ2FNEIzQn9W8v4kqYVef8ErH4LZkkJgsP50Nw838ZE NJwTRckleRmN3t7wy7RpUyuUBbEYXcaB/hONya2vR8Z2oUl+7CgbfBjvKjUrqILxyrCA ppsfDMXWX2kTi8vq2Z4H7PdBZDNBcFrNScV9a8hSqDZUAqDwZN7C3cC1QfdjTRTPsKe2 dykg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=UTzxxGzQPCGUTVrSvpxZdKn9viuOCJYpCiAl/PfwtPw=; b=HqwiYgKO6gn8vLPqQNHPKWJdyBEE1SQbZ0Nc2kB/SmPL3JEwBKJ0hmEeQ6Wl3vg0u5 T0Xm2q3qQPcmy8T58rjY2w62XE4hK/uyAcd2DKWiyVysXTbVKS3dWme4quyQ0idnoX7g oRpxKLOqT+76tHhUigG+SygLjjCEuqjXodRKIBNR4tq5w8SmVyCIuBZIQgHCkTsPv0+C cIMFOVaX0Gdi9IQ/FXhHz/rh0Ml3MDIF+I9B7vcV3QFJvlnTub66a3K4Kk4MZ1hlsYvU pQlwe28Vnbw+be35Hp17DnRdKxNeFfEEU6MiuucLKkeoTkhLOsz+0slXHHEt3yP/qsF1 1eig== X-Gm-Message-State: ALoCoQn2XfyjMPIn5bWuSNqGKQVbZiwEptpOFdbyRPyCzKuD6AN4gA3nfM9jFy7gLGG5WJhbLH3vGRODUVOpdsuqEBMSIDwQ6A== X-Received: by 10.194.75.202 with SMTP id e10mr46459140wjw.160.1453366206881; Thu, 21 Jan 2016 00:50:06 -0800 (PST) Received: from [10.16.0.189] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id c15sm28775772wmd.19.2016.01.21.00.50.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 00:50:05 -0800 (PST) To: "Montorsi, Francesco" , "dev@dpdk.org" References: <30b91c74ca26434daac041713cffa153@bilemail1.empirix.com> <569FAC72.3090001@6wind.com> From: Ivan Boule Message-ID: <56A09BAD.5030308@6wind.com> Date: Thu, 21 Jan 2016 09:49:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] where to find ethernet CRC when stripping is off X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 08:50:07 -0000 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