Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2671328imw; Wed, 6 Jul 2022 09:46:06 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u7vDdv/8xRL6GlVcdQ2BjgZLn7R0DNb+Jey8DrMRGmUwXwIBHZr6rkrXUMZ8dBxT0MB+Td X-Received: by 2002:a17:906:5a4e:b0:72a:605a:57c3 with SMTP id my14-20020a1709065a4e00b0072a605a57c3mr34180266ejc.301.1657125966478; Wed, 06 Jul 2022 09:46:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657125966; cv=none; d=google.com; s=arc-20160816; b=ZrlQ8558xpsmUoWySaMaMUIVAMCrPuDwpE/BgAZzqPHOUXE5OHLIzA4tmiQNTvnAsV Ig3rpa1CibxaBCWZYITCB5QcUkhQFvuPxKpJmS+ZmYzpbC3AMQmg3CMzaq+IOO4++uRM UuAQpXVpBWq8mK2Xz50PlLqovk/HS2TDY0QxJGOZZHRi2Vquxde+ob5BqD8KuhcspF3P 8Dw+q4jkfGa1ZccESn5b1IDjv5Vlgqahbempc6+4Jl8BHXVHVJZqYbBCyd+oorrIq266 xmFMpZdodURgyk3+lst0/5onFzXFi3cYw66iTulY6Cdxh2g+7ibe3kiBj61mlHRjER8C dy8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Dlq6ocRju/wsf2zkNUuYJY8keBab9BeuCt8KMsYue7U=; b=G/8dw9XXWRujQtU4Ago9xpKOcfXipKFkTesVfBPJxcvnLxI3At53NGaH1G5Vc+QZ3c yCjq/tqrduAhHtjWzLy4ZgJPO0aImOiUeH1vklnqxPm73HRI+vidwXaAxxszxqwKq7i1 YyrPaLM8Zjo4L4jVHJIWzSDRRnVnME3r5SZzKK20sxyNSmLYK3JDDSwXUUkdgSkFt+Ww 8YDH7YvprmsXwX8KAFLM6BuaSPI8jeVbT6rGWFTdsZvZUNC2ruRO+04G8Rtc6WgVMefM DGSESGw+Br3OLO5vV7hcsBUolpmEYEfljcTy8Uv9GCC7FA9Du6wAab96DsfGnQzVnWhR RJDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sb13-20020a1709076d8d00b00726e142a88esi3852623ejc.983.2022.07.06.09.45.40; Wed, 06 Jul 2022 09:46:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233303AbiGFQel (ORCPT + 99 others); Wed, 6 Jul 2022 12:34:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232969AbiGFQek (ORCPT ); Wed, 6 Jul 2022 12:34:40 -0400 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1121C1581C for ; Wed, 6 Jul 2022 09:34:39 -0700 (PDT) Received: by verein.lst.de (Postfix, from userid 2407) id ABB1E68BEB; Wed, 6 Jul 2022 18:34:34 +0200 (CEST) Date: Wed, 6 Jul 2022 18:34:34 +0200 From: Christoph Hellwig To: Keith Busch Cc: Christoph Hellwig , John Garry , axboe@fb.com, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] nvme: Fix nvme_setup_command metadata trace event for cdw10 Message-ID: <20220706163434.GA2222@lst.de> References: <1657095398-114310-1-git-send-email-john.garry@huawei.com> <20220706161825.GA1962@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 06, 2022 at 10:26:09AM -0600, Keith Busch wrote: > On Wed, Jul 06, 2022 at 06:18:25PM +0200, Christoph Hellwig wrote: > > On Wed, Jul 06, 2022 at 10:13:22AM -0600, Keith Busch wrote: > > > Did you test what the trace looks like afte this? We're losing valuable trace > > > data here. The field is supposed to get CDW's 10 - 15, so that's 24 bytes. I > > > don't know why it cares that the address of the field being read is only 4 > > > bytes; we want everything that comes after it too. > > > > Because accesses should not spawn boundaries of members in structs unless > > copying the entire struct. If we want to trace the various fields we > > need to individually assign them. > > > > Anyway, I'm dropping this patch from nvme-5.19 for now to let the > > discussion conclude. > > How about this instead? Maybe a better option would be to use struct_group().