On Fri, Feb 05, 2021 at 10:52:37AM +, Song Bao Hua (Barry Song) wrote:
> I assume there is no need to keep the same size with 5.11-rc, so
> could change the struct to:
>
> struct map_benchmark {
> __u64 avg_map_100ns; /* average map latency in 100ns */
> __u64 map_stddev; /* standa
er...@vger.kernel.org; linux...@openeuler.org
> Subject: Re: [PATCH v2] dma-mapping: benchmark: pretend DMA is transmitting
>
> On Fri, Feb 05, 2021 at 10:32:26AM +, Song Bao Hua (Barry Song) wrote:
> > I can keep the struct size unchanged by changing the struct to
> >
On Fri, Feb 05, 2021 at 10:32:26AM +, Song Bao Hua (Barry Song) wrote:
> I can keep the struct size unchanged by changing the struct to
>
> struct map_benchmark {
> __u64 avg_map_100ns; /* average map latency in 100ns */
> __u64 map_stddev; /* standard deviation of map latency */
>
ernel.org;
> linux...@openeuler.org
> Subject: Re: [PATCH v2] dma-mapping: benchmark: pretend DMA is transmitting
>
> On Fri, Feb 05, 2021 at 03:00:35PM +1300, Barry Song wrote:
> > + __u32 dma_trans_ns; /* time for DMA transmission in ns */
> > __u64 expansion[10];/*
On Fri, Feb 05, 2021 at 03:00:35PM +1300, Barry Song wrote:
> + __u32 dma_trans_ns; /* time for DMA transmission in ns */
> __u64 expansion[10];/* For future use */
We need to keep the struct size, so the expansion field needs to
shrink by the equivalent amount of data that is added
In a real dma mapping user case, after dma_map is done, data will be
transmit. Thus, in multi-threaded user scenario, IOMMU contention
should not be that severe. For example, if users enable multiple
threads to send network packets through 1G/10G/100Gbps NIC, usually
the steps will be: map -> trans
