From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: RING_HAS_UNCONSUMED_REQUESTS oddness Date: Thu, 6 Mar 2014 18:30:57 +0100 Message-ID: <20140306173057.GK11475@deinos.phlegethon.org> References: <5318987C.3030303@citrix.com> <1394121221.13270.10.camel@hastur.hellion.org.uk> <5318A2D8.3090808@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WLc8L-000156-5o for xen-devel@lists.xenproject.org; Thu, 06 Mar 2014 17:31:13 +0000 Content-Disposition: inline In-Reply-To: <5318A2D8.3090808@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Zoltan Kiss Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Ian Campbell List-Id: xen-devel@lists.xenproject.org At 16:31 +0000 on 06 Mar (1394119880), Zoltan Kiss wrote: > On 06/03/14 15:53, Ian Campbell wrote: > > On Thu, 2014-03-06 at 15:47 +0000, Zoltan Kiss wrote: > >> By my understanding, there is no way rsp could be smaller than req, so > >> there is no point having this. Am I missing something? > > > > It happens during wraparound, i.e. after req has wrapped but rsp hasn't > > yet. > > The name of the macro suggest we are interested whether the ring has > unconsumed requests, and netback uses it that way. The answer to that > question is req_prod - req_cons. And it works if prod wrapped but cons > didn't. Yes. > rsp calculates the number of "consumed but not responded" requests (it > also works well if req_cons wrapped but rsp_prod_pvt didn't), then > subtract it from the ring size. That is indeed an odd thing to check, since it seems like it could only be relevant if the request producer overran the response producer. It's been there in one form or another since the original ring.h, and RING_REQUEST_CONS_OVERFLOW does something similar. I can't remember the original reasoning, and so I'm reluctant to suggest removing it without some more eyes on the code... Tim.