From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by dpdk.org (Postfix) with ESMTP id DC2D15A84 for ; Mon, 9 Mar 2015 20:28:41 +0100 (CET) Received: by wiwl15 with SMTP id l15so24350088wiw.4 for ; Mon, 09 Mar 2015 12:28:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hyRTvxSuVHwPcMvV24Ss+zfaJKt+GLhsB/W8i4+2U7o=; b=UwMLBCD1eSG/KsJ/4HL4Ljyf+J8W1P8QxcPswZHKNUEpp6lgsveRyDnBEzpadKvsPz NTFDI65u2u0DmP9Emr3Up8r7sis4U2E8OwYyD/Z8tjVY5nXzY8O+InclZw7SfiYw71Cr arIndbgPmQ1AKNy95yTrSNZGevG1tfyvtY+bmZrziMT/lfxEYicn4/B5F/LOCNPcH5In mFJz6Y6EhIt2uqFV7mdyfV3FZ1A/Q2EesELnzyN0Eay0U9DXjKmD4+l69ruTPGBrWT5/ 8FMiEJSI/ryuYQi3KhmO3EcRS6Qkn+hsXkw1asesXjWkR5FRYXXxmwlQDvUSNurwXOVy nWFg== X-Gm-Message-State: ALoCoQn03xGYAIWrsNiMoJKW22xVXdf+Y/agEVxmPQghHRvwse/X1bs0j0Va0o1jFgJ2CbLv+vQz X-Received: by 10.194.200.229 with SMTP id jv5mr61731777wjc.59.1425929321752; Mon, 09 Mar 2015 12:28:41 -0700 (PDT) Received: from [10.0.0.2] (bzq-109-65-117-109.red.bezeqint.net. [109.65.117.109]) by mx.google.com with ESMTPSA id l6sm27241880wjx.33.2015.03.09.12.28.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Mar 2015 12:28:40 -0700 (PDT) Message-ID: <54FDF467.1090301@cloudius-systems.com> Date: Mon, 09 Mar 2015 21:28:39 +0200 From: Vlad Zolotarov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thomas Monjalon References: <1425823498-30385-1-git-send-email-vladz@cloudius-systems.com> <3162156.p89LbuxRO9@xps13> <54FD46FC.5010608@cloudius-systems.com> <2357467.DFWlgGcAaX@xps13> In-Reply-To: <2357467.DFWlgGcAaX@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v4 2/5] ixgbe: Bug fix: Properly configure Rx CRC stripping for x540 devices 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: Mon, 09 Mar 2015 19:28:42 -0000 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? PATCH4 doesn't have any refactoring - it fixes a design bug (actually two). The description of the patch is separated into two sections: one that describes how I did it and the second (starts with "Bugs fixed:") describes which bugs it fixes. When I re-read its description again now I see that I forgot to mention the second issue it fixes: there is the same problem for both Vector Rx callback initialization and for Bulk Rx callback initialization. In both cases in the current master tree the queue initialization code tries to initialize the port property (rx_pkt_bulk callback) which depends on all queues properties thus may be done only after all queues properties have been analyzed. More than that, some callbacks types may be used only when some combination of preconditions is met by all Rx queues: e.g. vector Rx may be used only when bulk (checks queue configuration) and vector (checks queue and port configuration) preconditions are met. Therefore I decided to introduce two port states that are a logical AND function of the appropriate queues' states. These states are used by a port configuration function that now can properly configure the callbacks. So, again - no refactoring here - a pure bug fix... ;) > > 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.