On 2018-02-14 16:20, Rosen Penev wrote:
> On Tue, Feb 13, 2018 at 11:10 PM, Felix Fietkau <n...@nbd.name> wrote:
>> On 2018-02-13 23:53, Rosen Penev wrote:
>>> Based on Qualcomm driver. Improves iperf3 throughput by ~20mbps on transmit
>>> on Archer C7v4.
>>>
>>> Signed-off-by: Rosen Penev <ros...@gmail.com>
>>> ---
>>> .../drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c | 14
>>> +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git
>>> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>>
>>> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>> index 95682b7641..d32f220178 100644
>>> ---
>>> a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>> +++
>>> b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
>>> @@ -797,11 +797,14 @@ static netdev_tx_t ag71xx_hard_start_xmit(struct
>>> sk_buff *skb,
>>> if (ag71xx_has_ar8216(ag))
>>> ag71xx_add_ar8216_header(ag, skb);
>>>
>>> - if (skb->len <= 4) {
>>> + dma_cache_sync (NULL, skb->data, skb->len, DMA_TO_DEVICE);
>> The use of dma_cache_sync here makes no sense, since it's the wrong API.
>> Also, effectively it results in the same kind of cache flush as the one
>> that's done by the DMA mapping done later.
>
> From my reading of dma_cache_flush, I agree. However that's the part
> of this patch that gives the biggest speedup. Before this patch, I
> tested just adding that and it worked. I can back this up with
> benchmarks later on.
In my test I quite often encountered big differences in throughput from
minor (and often very much unrelated) changes. I haven't found the real
source of these differences yet, so it's hard to know which changes
really help in the long run. My best guess is that some changes affect
the alignment of critical functions and thus affect the icache footprint
somehow.
Until I see a reasonable explanation of how this change helps, I'm going
to assume it's the same kind of random change fluctuation that I've seen
so often and NACK this change.
- Felix
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
