From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by dpdk.org (Postfix) with ESMTP id F3D882BCF for ; Mon, 21 Mar 2016 03:26:43 +0100 (CET) Received: by mail-yw0-f179.google.com with SMTP id g3so201126206ywa.3 for ; Sun, 20 Mar 2016 19:26:43 -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=+rgSCMbvkJz5Cxe4zGlMu23ccAVB0Id+BN90p3iEzsQ=; b=J+zzkpeJmCPSIZqscFjhnChLE344SXN5MxgfVRCewcI4rsqGqCFDMJww9MEQUsGPIY c31aXOft5owxSpDkTfw/POJ0QQGsJ9L5rRsY/2gvCyjkYhg1DJvdoaPa//Sm12RT/Bpv bhbWutX/KSi8ywS05G+tx/wqbhMPMdrpI2BsQ= 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=+rgSCMbvkJz5Cxe4zGlMu23ccAVB0Id+BN90p3iEzsQ=; b=Z526ED2LexrDXtlbsKoVz9yz7dvLPlXmZBcphXR8Xh2BgARUb55j/NXOQwVFgd88IJ nK3HErbf/j9rRyePoSOrNNMbb1/DkdxkY+3l4RyTknQaL1woVXwHcthqs9n1fz0OJ665 7GGWyJQIlXlCGkPMaLrhoD6Qcelj5UA8oM6EHFQlulyUDmIQGAlWoY+7HeQYcZkcQTnK mttspRSrq7LuBSFn34Z1PIH1UWnAykPF31kmtAdsghRO1NtffQZg7UXai6uRThBYFkWY WSmM95Q+ak08/JSN5C+SahzLx70Aqpt7Jdnfj9QeQLGOF+JXIHdzHRbeLlmdPFH2TKdm aeyA== X-Gm-Message-State: AD7BkJLb3Thy2bCSuPZ7JNaLUTrteGqRD8+Sr2NocrGIvs/3ZlFBSJT+lbrlXGi5SfFtySwuMBPnP8Yh0gdD5JlJ MIME-Version: 1.0 X-Received: by 10.13.225.133 with SMTP id k127mr12393918ywe.20.1458527203456; Sun, 20 Mar 2016 19:26:43 -0700 (PDT) Received: by 10.37.209.212 with HTTP; Sun, 20 Mar 2016 19:26:43 -0700 (PDT) In-Reply-To: <20160318100358.GA4848@bricha3-MOBL3> References: <1457965558-15331-1-git-send-email-jianbo.liu@linaro.org> <6A0DE07E22DDAD4C9103DF62FEBC09090343BBF2@shsmsx102.ccr.corp.intel.com> <20160316111454.GB24668@bricha3-MOBL3> <20160318100358.GA4848@bricha3-MOBL3> Date: Mon, 21 Mar 2016 10:26:43 +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: Mon, 21 Mar 2016 02:26:44 -0000 On 18 March 2016 at 18:03, Bruce Richardson wrote: > On Thu, Mar 17, 2016 at 10:20:01AM +0800, Jianbo Liu wrote: >> 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 > HI Jianbo, > > ok, I understand now. I'm not sure that this is a significant problem though, > since we are working in polling mode. Is there a performance impact to your > change, because I don't think that we can reduce performance just to fix this? > > Regards, > /Bruce It will be a problem because the possibility could be high. Considering rx hwring size is 128 and rx burst is 32, the possiblity can be 32/128. I know this change is critical, so I want you (and maintainers) to do full evaluations about throughput/latency..before making conclusion. Jianbo