From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Zolotarov Subject: Re: [PATCH v4 2/5] ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices Date: Mon, 09 Mar 2015 18:10:24 +0200 Message-ID: <54FDC5F0.8050901@cloudius-systems.com> References: <1425823498-30385-1-git-send-email-vladz@cloudius-systems.com> <3162156.p89LbuxRO9@xps13> <54FD46FC.5010608@cloudius-systems.com> <2357467.DFWlgGcAaX@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Thomas Monjalon Return-path: In-Reply-To: <2357467.DFWlgGcAaX@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" On 03/09/15 09:58, Thomas Monjalon wrote: > 2015-03-09 09:08, Vlad Zolotarov: >> On 03/08/15 23:12, Thomas Monjalon wrote: >>> Hi Vlad, >>> >>> 2015-03-08 16:04, Vlad Zolotarov: >>>> According to x540 spec chapter 8.2.4.8.9 CRCSTRIP field of RDRXCTL should >>>> be configured to the same value as HLREG0.RXCRCSTRP. >>>> >>>> Clearing the RDRXCTL.RSCFRSTSIZE field for x540 is not required by the spec >>>> but seems harmless. >>>> >>>> Signed-off-by: Vlad Zolotarov >>> You are mixing a fix (this patch) and enhancements (LRO) in the same series. >>> Could you separate them please, as LRO is not going into 2.0 but this fix >>> is a good candidate. >> Pls, note that all patches in this series except for PATCH3 and PATCH5 >> are fixing real bugs. I can send them as a separate series if u'd like. >> Pls., confirm. > Yes you're right, patch 1 is also a fix and patch 4 seems to solve other > issues. However, patch 4 makes also some refactoring and seems a bit risky. > We need an ixgbe maintainer to decide wether we can merge it before the > release. Or is it possible to have fixes of the patch 4 without the > refactoring? > > Thanks Vlad. > Sorry to request such split but this PMD is sensible and I don't want to > have a risk of making it worst in release 2.0. Well, IMHO PATCH4 here has the most important and critical fix among other patches - the whole port is going to be configured according to the last queue configuration. Consider the case when queues are configured differently and the last one meets vector Rx requirements: bulk allocation requirements, descriptors number is a power of 2 (there are per-port requirements too). But the first queue may be configured to have a different number of descriptors, which is NOT a power of two. Currently the port's rx_pkt_burst callback will be configured to use a vercot Rx callback and we would hit the same issue reported by Stephen and "fixed" in 352078e8e.