From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::344; helo=mail-wm1-x344.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C8E1E21184AAB for ; Tue, 30 Oct 2018 05:50:11 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id f1-v6so11838946wmg.1 for ; Tue, 30 Oct 2018 05:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0BZ2qPAjkghwK9y6hmwzbqXekAqbuXy6IniGkpjSxT8=; b=h7vdEyb3CNiEGcFGhFNwkZzuRKaIq9+lxpkNaoi4QGNjzT2stjpxxD/KfVBrtnw509 YnRQp+FoU1QFenTo3aR8U70EUtG73N+zOZr1vedpezJVr6frCS9yukwTFcYL2aQQEkL7 ERkfPFa6Zd3G/KUtauA83uc7nRvSoWwLZ2VP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0BZ2qPAjkghwK9y6hmwzbqXekAqbuXy6IniGkpjSxT8=; b=EAiSr8u6DkWxnpAwMzSiH/6H9gEtu6gThZBjbKn9By2IOkbiYe3BRI1o0E1IfW/kgx Zib07d0leTFFRHTC/RBf25AP4DnqfIQtBs63t4Vdvsh35ltuEIFuzWR3efKs+ZxBUjMF v9CS7fRTx8USo9d2KZSV0mh37DojMQKF9gxCAyAUIYzF2lvHMbdovG42ctIWG6Q3tXM4 FOm3Qqb6EwleBMYDlII9wUVf0D2nHyWLPApyZI5ldD7LRVBSWnaUuXumJ+XvcAlsIN4r TOfcAngZCJeAFX4BRERr9t7jUnIXp+EGuDaqKGzEl1Zn3jMB0SB3pXgnQQc9/bIJBaYY NeWA== X-Gm-Message-State: AGRZ1gJPyLqWf+AllEJxDe95avnGX2B/3AwiknNhnGTkkgU8cYkf1AhS YYfzIVNpm2JtwGl7s07PB29R1Q== X-Google-Smtp-Source: AJdET5ccAXJ5Ovr1zYFK6SPzYPPxo+pjPi+oruMTpX6bFTNMWNZMVAp1eAVFDPQJp1RlT/QX/SDiPw== X-Received: by 2002:a1c:4489:: with SMTP id r131-v6mr1735768wma.121.1540903809432; Tue, 30 Oct 2018 05:50:09 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id n76-v6sm3747284wmd.47.2018.10.30.05.50.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 30 Oct 2018 05:50:08 -0700 (PDT) Date: Tue, 30 Oct 2018 12:50:06 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: "Cohen, Eugene" , edk2-devel-01 , Star Zeng Message-ID: <20181030125006.4deveknlhrwehllb@bivouac.eciton.net> References: <1540561286-112684-1-git-send-email-star.zeng@intel.com> <1540561286-112684-5-git-send-email-star.zeng@intel.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH V3 4/4] MdeModulePkg EhciDxe: Use common buffer for AsyncInterruptTransfer X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 12:50:12 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 30, 2018 at 09:39:24AM -0300, Ard Biesheuvel wrote: > (add back the list) Oi! Go back on holiday! > On 30 October 2018 at 09:07, Cohen, Eugene wrote: > > Has this patch been tested on a system that does not have coherent DMA? > > > > It's not clear that this change would actually be faster on a system of that > > type since using common buffers imply access to uncached memory. Depending > > on the access patterns the uncached memory access could be more time > > consuming than cache maintenance operations. > > I haven't had time to look at these patches yet. > > I agree with Eugene's concern: the directional DMA routines are much > more performant on implementations with non-coherent DMA, and so > common buffers should be avoided unless we are dealing with data > structures that are truly shared between the CPU and the device. > > Since this is obviously not the case here, could we please have some > numbers about the performance improvement we are talking about here? > Would it be possible to improve the IOMMU handling code instead? On an unrelated note to the concerns above: Why has a fundamental change to the behaviour of one of the industry standard drivers been pushed at the very end of the stable cycle? Regards, Leif