On 2020/2/20 20:20, John Garry wrote:
On 20/02/2020 12:16, Xu Zaibo wrote:
On 2020/2/20 19:07, John Garry wrote:
On 20/02/2020 10:10, Xu Zaibo wrote:
Hi,
On 2020/2/20 17:50, John Garry wrote:
On 20/02/2020 09:04, Zaibo Xu wrote:
From: liulongfang <liulongfang@xxxxxxxxxx>
In the scenario of SMMU translation, the SEC performance of short
messages
(<512Bytes) cannot meet our expectations. To avoid this, we
reserve the
plat buffer (PBUF) memory for small packets when creating TFM.
I haven't gone through the code here, but why not use this method
also for non-translated? What are the pros and cons?
Because non-translated has no performance or throughput problems.
OK, so no problem, but I was asking could it be improved, and, if
so, what would be the drawbacks?
As for the change to check if the IOMMU is translating, it seems
exact same as that for the hi1616 driver...
Currently, I find the only drawback is needing more memory :),
OK, so that is a drawback.
what's your idea?
I am just asking if we get any performance gain for using this same
method for non-IOMMU case, and does the gain (if any) in performance
outweigh the additional memory usage?
Sorry for my misunderstanding. As our testing, no gain for no-iommu
case, because of memory copy.
Yes, the same as SEC V1.
So it could be factored out :)
It is a good idea. However, now SEC V1 and V2 are in different
directories, more, this checking logic is quite simple.
And for our HPRE and ZIP, there is no performance or throughput problem
as IOMMU on.
Cheers,
Zaibo
.
thanks,
john
.