From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7773A1C879E for ; Thu, 24 Oct 2024 11:05:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729767932; cv=none; b=CoHwb/hBV6SAe+7DFVh89hSNlqmNIURmxqfrziLXjzMYgUV8sYddoLOLZiLfftawwXFT/SXmrjUB3fDqYIz6Yb8G+/nf9GHTvqFnbIuHNpiaPOWmUg4iQWiNeTwArfRIVhasB+got49Osd4/xpDCgVoh4zBhYzZLXOcMBj4g+OQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729767932; c=relaxed/simple; bh=jjYyuGSzLYvDtOugSCGUhJhszVe3Gt9vmFcAv/ZyuH0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=iZnjfPaSqQ59sEIBs/4kQxTCYBeEjbHePeDEqX3fXjXwVSd2fNfdcqUZNELmenXYGK+vSP5ar913Luw5G6tXauPagZMDRJvy1ex0l3ZRVZ37ZfrIYNxHKzdzgnRZXTEzYifQburTwqqy/4n22F/hXJ5IrJVAy+QHPE7TPslMHyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FFKSV+Ok; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FFKSV+Ok" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729767929; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g7OjTvApAV59HVeae52wE1LhAHSP+BKWM42WMsGZKZU=; b=FFKSV+OkfHvMR0PUaZeVVR14APSEQaZgP1YeDHQ80OQF/N86Iav0gNPkILcZglHsiotifu QihKetMxL/Yb0JcrmaKImZJwW7+p9OsUtGslA72kOdmoUXKzsvvpYbhcKcV+UqIHXUXBOh 5/svZuiDjsDDEeVdlPHoJ4dsjLJoFyY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-590-jwSgfMEHO12SSv-Da4-yeg-1; Thu, 24 Oct 2024 07:05:28 -0400 X-MC-Unique: jwSgfMEHO12SSv-Da4-yeg-1 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-37d533a484aso982792f8f.0 for ; Thu, 24 Oct 2024 04:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729767927; x=1730372727; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g7OjTvApAV59HVeae52wE1LhAHSP+BKWM42WMsGZKZU=; b=eXF0yiNkEzygZ+AKlDMThPUJtAQuNstx5A9dkeaSiW98HiWAD4F5/DDK4XTyAdfC4o suTnAsjRcgrwlNQguf1IBFu22YlCyWCMWMtbhFcBwEMjmU+LUraf4CBarvk848Mr6Dzz 3ghJbpAP32TNpAiudTS/4bJv6qTgY5g36CEP4m1VtQlULkzHmGuJG9QAPbdOd+WasGh/ /BSDi1u1NMhtLPt1DQuGCMETJxlP/cZFdmF7S4WOiT4poAsFPX7Vo/Y9jiXRytKI0A01 OEAF357VElIzxkfNuZTAIbhOQbh8Hca4c96VfRhAGhjbpC6qaHio4lQJvy2Gc/+cIdbP Ko0g== X-Forwarded-Encrypted: i=1; AJvYcCVMXlkDHOLsvXZj6YHrwbJLEX5WBpBE6Kmkcvsh2XLFi5eyYL4gKHqB4PGc2EkYl7inC67/GaBY0gpZxKc=@vger.kernel.org X-Gm-Message-State: AOJu0YyM7krsxSG9jvEZol5Pn+nTsCzrReMK+cOXpmXXztABG3k5hhDy JrC+JdGvB4ugmGtX6N2R0zbPNYKOO86JS/9uAac32vl6qLByroQy76eb5ix21bpzlK14/dqfX9w 9budrcFXQMxcdMsxf1peY5TE5VvHqkbsYMv4sZtGXSPlPNFKd+JwDvd2vGMAY1g== X-Received: by 2002:a5d:50c6:0:b0:37d:364c:b410 with SMTP id ffacd0b85a97d-3803ac8e202mr923124f8f.33.1729767927000; Thu, 24 Oct 2024 04:05:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEy6EiR8rruLA2inrEtuBgfLw2q2XQ4rEH0M7V9j0fn7ncp1qxHUAZ7YmyoWo3EDUeuY9sFJA== X-Received: by 2002:a5d:50c6:0:b0:37d:364c:b410 with SMTP id ffacd0b85a97d-3803ac8e202mr923099f8f.33.1729767926622; Thu, 24 Oct 2024 04:05:26 -0700 (PDT) Received: from ?IPV6:2a0d:3344:1b73:a910::f71? ([2a0d:3344:1b73:a910::f71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37ee0a585f7sm10890341f8f.51.2024.10.24.04.05.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Oct 2024 04:05:26 -0700 (PDT) Message-ID: <79005e6e-543e-444b-9acc-f59ac7b04675@redhat.com> Date: Thu, 24 Oct 2024 13:05:24 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2 net 2/9] net: hns3: add sync command to sync io-pgtable To: "shenjian (K)" , Jijie Shao , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, salil.mehta@huawei.com Cc: liuyonglong@huawei.com, wangpeiyang1@huawei.com, lanhao@huawei.com, chenhao418@huawei.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20241018101059.1718375-1-shaojijie@huawei.com> <20241018101059.1718375-3-shaojijie@huawei.com> <214d37cc-96c0-4d47-bea0-3985e920d88c@redhat.com> Content-Language: en-US From: Paolo Abeni In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/24/24 11:38, shenjian (K) wrote: > > 在 2024/10/24 16:36, Paolo Abeni 写道: >> On 10/18/24 12:10, Jijie Shao wrote: >>> From: Jian Shen >>> >>> To avoid errors in pgtable prefectch, add a sync command to sync >>> io-pagtable. >>> >>> In the case of large traffic, the TX bounce buffer may be used up. >> It's unclear to me what do you mean for large traffic. Is that large >> packets instead? >> >> Skimming over the previous patch, it looks like the for the bugger H/W >> driver will use the bounce buffer for all packets with len < 64K. As >> this driver does not support big tcp, such condition means all packets. >> >> So its not clear to me the 'may' part - it looks like the critical path >> will always happen on the bugged H/W > > Sorry for the unclear commit log. > > Yes, we don't support big tcp, so <64K is worked for all packets. The > large traffic > > here is just want to describe a case that tx bounce buffer is used up, > and there is > > no enough space for new tx packets. > > >>> At this point, we go to mapping/unmapping on TX path again. >>> So we added the sync command in driver to avoid hardware issue. >> I thought the goal of the previous patch was to avoid such sync-up. >> >> So I don't understand why it's there. >> >> A more verbose explanation will help. > > This is a supplement for the previous patch. We want all the tx packet can > > be handled with tx bounce buffer path. But it depends on the remain space > > of the spare buffer, checked by the function hns3_can_use_tx_bounce(). In > > most cases, maybe 99.99%, it returns true. But once it return false by no > > available space, the packet will be handled with the former path, which > > will map/unmap the skb buffer. Then we will face the smmu prefetch risk > again. > > So I add a sync command in this case to avoid smmu prefectch, > > just protects corner scenes. > > >>> Signed-off-by: Jian Shen >>> Signed-off-by: Peiyang Wang >>> Signed-off-by: Jijie Shao >> Also we need a fixes tag. > > We considered this issue, and since this is not a software defect, we > were not too > > sure which commit should be blamed. > > It makes sense to choose the commit introducing the support for the > buggy H/W, we will add > > it. Please additionally rephrase the commit message including the more verbose explanation above, thanks! Paolo