From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by dpdk.org (Postfix) with ESMTP id 7D5192C59 for ; Thu, 17 Mar 2016 03:20:02 +0100 (CET) Received: by mail-yw0-f171.google.com with SMTP id m126so60456614ywd.0 for ; Wed, 16 Mar 2016 19:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=XEZ/tIlRExsVpPgAl/X0Y+uxrqJHitADcKhqIRiL1pQ=; b=GIakkedMcNUauTHFCYoZ6Yr1JvbCkzu+ontaeIpA2vAVSa8kaUBcfS+CdZbTsBQWAI PiFDSR/5jPZ4IV9LTxcrOUxnYBrwYwlN0feL5XFDrfjMe8RBcemOQxbSfrY3ij9UjLXQ SZpkMk0Z/Qeq5rDUThwdh5Um2d6t8bI8x3KfI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=XEZ/tIlRExsVpPgAl/X0Y+uxrqJHitADcKhqIRiL1pQ=; b=h4UihTOXKZGmnjgACqpHdq+h+L80Cpd2sl2TA1xx6UQnKKH6VW2Sl+N6mTNLoGl5Nz 9O6xcZM7NkZqwpuFWVuksmlLuc336LGfiLeGn+Szr+dESRd6dHWPLIKIrrE367oKvc/t GJKyIhipJg+TrDCicItVKkxCVP4Yw5uw25aucygoFJ8eVi82BYwEBwKR3416bntDBOKp 7jOqxdgCysFtVJQ22Qs8pYJinLBKIJGTFm2VUEp6VKEAZ5Gku42UBiwnbO8EMQFvuNSV 9qqZFrE5+XDW4UwoRRWiPHEvUZxXlA2o2bh1NFAx5f19snEaJCn7PxwixikWgVE4N0Ba 2nAw== X-Gm-Message-State: AD7BkJISk9M10/VJIqbBL6Yu/q4pXFCNi0HAdkGsxI/Cscm31my4/jbeBgNmT9CH/2IV33khbzw2oD8hBlRuVYQ1 MIME-Version: 1.0 X-Received: by 10.37.230.204 with SMTP id d195mr2906557ybh.127.1458181201992; Wed, 16 Mar 2016 19:20:01 -0700 (PDT) Received: by 10.37.209.23 with HTTP; Wed, 16 Mar 2016 19:20:01 -0700 (PDT) In-Reply-To: <20160316111454.GB24668@bricha3-MOBL3> References: <1457965558-15331-1-git-send-email-jianbo.liu@linaro.org> <6A0DE07E22DDAD4C9103DF62FEBC09090343BBF2@shsmsx102.ccr.corp.intel.com> <20160316111454.GB24668@bricha3-MOBL3> Date: Thu, 17 Mar 2016 10:20:01 +0800 Message-ID: From: Jianbo Liu To: Bruce Richardson Cc: "Lu, Wenzhuo" , "Zhang, Helin" , "Ananyev, Konstantin" , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring 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, 17 Mar 2016 02:20:02 -0000 On 16 March 2016 at 19:14, Bruce Richardson wrote: > On Wed, Mar 16, 2016 at 03:51:53PM +0800, Jianbo Liu wrote: >> Hi Wenzhuo, >> >> On 16 March 2016 at 14:06, Lu, Wenzhuo wrote: >> > HI Jianbo, >> > >> > >> >> -----Original Message----- >> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jianbo Liu >> >> Sent: Monday, March 14, 2016 10:26 PM >> >> To: Zhang, Helin; Ananyev, Konstantin; dev@dpdk.org >> >> Cc: Jianbo Liu >> >> Subject: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the >> >> tail of rx hwring >> >> >> >> When checking rx ring queue, it's possible that loop will break at the tail while >> >> there are packets still in the queue header. >> > Would you like to give more details about in what scenario this issue will be hit? Thanks. >> > >> >> vPMD will place extra RTE_IXGBE_DESCS_PER_LOOP - 1 number of empty >> descriptiors at the end of hwring to avoid overflow when do checking >> on rx side. >> >> For the loop in _recv_raw_pkts_vec(), we check 4 descriptors each >> time. If all 4 DD are set, and all 4 packets are received.That's OK in >> the middle. >> But if come to the end of hwring, and less than 4 descriptors left, we >> still need to check 4 descriptors at the same time, so the extra empty >> descriptors are checked with them. >> This time, the number of received packets is apparently less than 4, >> and we break out of the loop because of the condition "var != >> RTE_IXGBE_DESCS_PER_LOOP". >> So the problem arises. It is possible that there could be more packets >> at the hwring beginning that still waiting for being received. >> I think this fix can avoid this situation, and at least reduce the >> latency for the packets in the header. >> > Packets are always received in order from the NIC, so no packets ever get left > behind or skipped on an RX burst call. > > /Bruce > I knew packets are received in order, and no packets will be skipped, but some will be left behind as I explained above. vPMD will not received nb_pkts required by one RX burst call, and those at the beginning of hwring are still waiting to be received till the next call. Thanks! Jianbo