Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp262421pxj; Tue, 18 May 2021 02:48:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6BETpfPpSzQnMnTDvclwfOjYbhibicJoLD2RTL0d337GA+3eV/hBwekgkPlsg2mjS2CC5 X-Received: by 2002:a92:6b02:: with SMTP id g2mr3430014ilc.23.1621331331171; Tue, 18 May 2021 02:48:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621331331; cv=none; d=google.com; s=arc-20160816; b=BsrSgOYTQ4FEu+JwREbTeuDilHYTobU/+woEGz9nXhOiax+nnA5O3ZZTQgtTSOPG66 Lu09hPV+h34o3JSj0VtsJ+6Kvr9zccCOJgTiNnXkkWTdr+HID4niWZJc0CbEvRUmj08z LaHqnRSCMYCWjxJmXe3IoFIDvm3VjcBpAXNQMWVlIMxNItVQf9IGZPXg6C4HpxrPJqEq 1psKSeDo+QXK+QMU41yD+Tnc/TALrLnc44F4s4EiARVfbui7A5IkT5cJz1LHcaBTQfR9 wcJAQxoX3RdmYCSm1X4mHyfEETNlhSRBSUEmfqvDgFpNFT9gNOWAmt86GpbPQGb5s01D MLiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TZ19gTcmPO4a3EZaIyWBcOYXBxCKYE7Cve2jyRg7ZgE=; b=NTIm2tO0b7rSBfLqMSyNH1Np3hT6DxyuoSz8D4kTmFzNjBVOQ39ES2zxToPd2IiAiS ovens/W9xRKCPadPYZBSrB3gRLZzA8EMmLwISGRrS9sPyVAQwZB6ecqW5dpO9Cifsp/E f2tkku5FVsj8Xzpw6nKGoJ6jYqiP0LXuO6uzA390Ai2v7Koigu+VrWggPMS/U8YkDNOa oi9bjLBjLkcLZYbqQIbuYOUkR7zAC0bOsK2G+F/UoDljVxIcZmCZXMdtHjB3T/oW0d+w 9OjJUunyFnij65TfN1b4ZI0qptESRSSIP0wm7zU8C8J9SHXBYGALb3PvfR7QRK1vghM0 zogw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p15si22933980ilo.83.2021.05.18.02.48.38; Tue, 18 May 2021 02:48:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243130AbhEQPJR (ORCPT + 99 others); Mon, 17 May 2021 11:09:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:44004 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242211AbhEQO7X (ORCPT ); Mon, 17 May 2021 10:59:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F151FAEBB; Mon, 17 May 2021 14:58:05 +0000 (UTC) Date: Mon, 17 May 2021 16:58:05 +0200 From: Daniel Wagner To: Sagi Grimberg Cc: Keith Busch , Hannes Reinecke , "Ewan D. Milne" , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, Jens Axboe , Christoph Hellwig Subject: Re: [PATCH v2] nvme-tcp: Check if request has started before processing it Message-ID: <20210517145805.end32zjhqfjh6kga@beryllium.lan> References: <20210311094345.ogm2lxqfuszktuhp@beryllium.lan> <70af5b02-10c1-ab0b-1dfc-5906216871b4@grimberg.me> <2fc7a320c86f75507584453dd2fbd744de5c170d.camel@redhat.com> <20210330232813.GA1935968@dhcp-10-100-145-180.wdc.com> <756aef10-e693-276f-82ac-514a2832b07f@grimberg.me> <492b8393-fc35-f58a-3768-94632a083c93@suse.de> <3156c563-94a4-4278-3835-b1f56f71869a@grimberg.me> <20210507204052.GA1485586@dhcp-10-100-145-180.wdc.com> <7a45dd7f-842b-4282-909b-082b501abcdc@grimberg.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a45dd7f-842b-4282-909b-082b501abcdc@grimberg.me> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sagi, On Fri, May 07, 2021 at 04:22:30PM -0700, Sagi Grimberg wrote: > Yea, maybe something like this? I did give this a spin with blktests (loopback device) and on real hardware (FC). Seems to do work fine. Just two things. > +/* > + * nvme command_id is constructed as such: > + * | xxxx | xxxxxxxxxxxx | > + * gen request tag > + */ > +#define nvme_cid_install_genctr(gen) ((gen & 0xf) << 12) > +#define nvme_genctr_from_cid(cid) ((cid & 0xf000) >> 12) > +#define nvme_tag_from_cid(cid) (cid & 0xfff) > + > +static inline u16 nvme_cid(struct request *rq) > +{ > + return nvme_cid_install_genctr(nvme_req(rq)->genctr++) | rq->tag; > +} - return nvme_cid_install_genctr(nvme_req(rq)->genctr++) | rq->tag; + nvme_req(rq)->genctr = ++nvme_req(rq)->genctr & 0xf; + return nvme_cid_install_genctr(nvme_req(rq)->genctr) | rq->tag; The first issue, it really needs prefix increment if you want to write it in one line. And it should store only the first 4 bits. nvme_find_rq() would complain with 0x0 != 0x10 after the first overflow. > +static inline struct request *nvme_find_rq(struct blk_mq_tags *tags, > + u16 command_id) > +{ > + u8 genctr = nvme_genctr_from_cid(command_id); > + u16 tag = nvme_tag_from_cid(command_id); > + struct request *rq; > + > + rq = blk_mq_tag_to_rq(tags, tag); > + if (unlikely(!rq)) { > + pr_err("could not locate request for tag %#x\n", > + tag); > + return NULL; > + } > + if (unlikely(nvme_req(rq)->genctr != genctr)) { > + dev_err(nvme_req(rq)->ctrl->device, > + "request %#x genctr mismatch (got %#x expected > %#x)\n", > + tag, nvme_req(rq)->genctr, genctr); - tag, nvme_req(rq)->genctr, genctr); + tag, genctr, nvme_req(rq)->genctr); The arguments are in the wrong order. Got me a bit confused. Are you going to send out a proper patch? I'd like to move things forward and could offer to do some more testing if needed. Thanks, Daniel