[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <79005e6e-543e-444b-9acc-f59ac7b04675@redhat.com>
Date: Thu, 24 Oct 2024 13:05:24 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: "shenjian (K)" <shenjian15@...wei.com>, Jijie Shao
<shaojijie@...wei.com>, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, salil.mehta@...wei.com
Cc: liuyonglong@...wei.com, wangpeiyang1@...wei.com, lanhao@...wei.com,
chenhao418@...wei.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 net 2/9] net: hns3: add sync command to sync io-pgtable
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 <shenjian15@...wei.com>
>>>
>>> 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 <shenjian15@...wei.com>
>>> Signed-off-by: Peiyang Wang <wangpeiyang1@...wei.com>
>>> Signed-off-by: Jijie Shao <shaojijie@...wei.com>
>> 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
Powered by blists - more mailing lists