netdev - RE: [PATCH] net: fec_main: dma_map() only the length of the skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Dec 2013 02:14:17 +0000
From:	Fugang Duan <fugang.duan@...escale.com>
To:	Fugang Duan <fugang.duan@...escale.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"David S. Miller" <davem@...emloft.net>,
	Fabio Estevam <Fabio.Estevam@...escale.com>,
	Frank Li <frank.li@...escale.net>,
	Jim Baxter <jim_baxter@...tor.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: RE: [PATCH] net: fec_main: dma_map() only the length of the skb

From: Fugang Duan <fugang.duan@...escale.com>
Data: Monday, December 02, 2013 10:05 AM + 800

>To: Sebastian Andrzej Siewior; netdev@...r.kernel.org
>Cc: David S. Miller; Estevam Fabio-R49496; Frank Li; Jim Baxter; Marek
>Szyprowski
>Subject: RE: [PATCH] net: fec_main: dma_map() only the length of the skb
>
>From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>Data: Wednesday, November 27, 2013 8:44 PM
>
>>To: netdev@...r.kernel.org
>>Cc: David S. Miller; Estevam Fabio-R49496; Frank Li; Duan
>>Fugang-B38611; Jim Baxter; Marek Szyprowski; Sebastian Andrzej Siewior
>>Subject: [PATCH] net: fec_main: dma_map() only the length of the skb
>>
>>On tx submit the driver always dma_map_single() FEC_ENET_TX_FRSIZE
>>(=2048) bytes. This works because we don't overwrite any memory after
>>the data buffer, we remove it from cache if it was there. So we hurt
>>performace in case the mapping of a smaller area makes a difference.
>>There is also a bug: If the data area starts shortly before the end of
>>RAM say
>>0xc7fffa10 and the RAM ends at 0xc8000000 then we have enough space to
>>fit the data area (according to skb->len) but we would map beyond end
>>of ram if we are using 2048. In v2.6.31 (against which kernel this
>>patch
>>made) there is the following check in dma_cache_maint():
>>
>>|BUG_ON(!virt_addr_valid(start) || !virt_addr_valid(start + size - 1));
>>
>>Since the area starting at 0xc8000000 is no longer virt_addr_valid() we
>>BUG() during dma_map_single(). The BUG() statement was removed in
>>v3.5-rc1 as per 2dc6a016 ("ARM: dma-mapping: use asm-generic/dma-mapping-
>common.h").
>>
>>This patch was tested on v2.6.31 and then forward-ported and compile
>>tested only against the net tree. I think it is still worth fixing
>>mainline even after the BUG() statement is gone.
>>
>>Cc: Marek Szyprowski <m.szyprowski@...sung.com>
>>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>>---
>>
[...]
>It pass weekend stress test, and performance have little change for imx6q
>sabresd platform(cpu frequence is 799MHz, set cpufreq governor to performance):
>The previous tx bandwidth for tcp: 427Mhz After the patch, tx bandwidth for tcp:
>440Mhz.

427Mhz -> 427Mbps
440Mhz -> 440Mbps

>It means dma map memory size can impact networking performance.
>
>
>
>Tested-by: Fugang Duan <B38611@...escale.com>
>
>Thanks,
>Andy
>

Sorry, it is slip of the pen.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html