summaryrefslogtreecommitdiffstats
path: root/drivers/clk/Makefile
diff options
context:
space:
mode:
authorChristophe Leroy <christophe.leroy@c-s.fr>2016-09-09 14:26:23 +0200
committerDavid S. Miller <davem@davemloft.net>2016-09-11 06:17:13 +0200
commit070e1f01827c658b76bef6e3fa79046b4e4a7693 (patch)
treeb4689b5004ea96ae0ca37b8ed7435508eb6b4be5 /drivers/clk/Makefile
parentnet: fs_enet: merge NAPI RX and NAPI TX (diff)
downloadlinux-070e1f01827c658b76bef6e3fa79046b4e4a7693.tar.xz
linux-070e1f01827c658b76bef6e3fa79046b4e4a7693.zip
net: fs_enet: don't unmap DMA when packet len is below copybreak
When the length of the packet is below the defined copybreak limit, the received packet is copied into a newly allocated skb in order to reuse the skb. This is only interesting if it allow us to avoid a new DMA mapping. We shall therefore not DMA unmap and remap the skb->data. Instead, we invalidate the cache with dma_sync_single_for_cpu() once the received data has been copied into the new skb. The following measures have been obtained on a mpc885 running at 132Mhz. Measurement is done using the timebase with packets sent to the target with 'ping -s 1' (packet len is 60): * Without this patch: 182 TB ticks * With this patch: 143 TB ticks As a comparison, if we set the copybreak limit to 0, then we get 148 TB ticks. It means that without this patch, duration is even worse when copying received data to a new skb instead of allocating a new skb for next packet to be received Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/clk/Makefile')
0 files changed, 0 insertions, 0 deletions