[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.03.1408160047360.5614@ws.cisco>
Date: Sat, 16 Aug 2014 01:51:32 +0530 (IST)
From: Govindarajulu Varadarajan <_govind@....com>
To: David Laight <David.Laight@...LAB.COM>
cc: 'Govindarajulu Varadarajan' <_govind@....com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ben@...adent.org.uk" <ben@...adent.org.uk>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
"ssujith@...co.com" <ssujith@...co.com>,
"benve@...co.com" <benve@...co.com>
Subject: RE: [PATCH net-next v3 0/3] enic: Add support for rx_copybreak
On Thu, 14 Aug 2014, David Laight wrote:
> Is there any mileage in having a system-wide default for rx_copybreak?
> I'd have thought that the value is really driver independent since it
> (mostly) depends on the comparative cost of dma_map and copy operations.
>
The cost skb_alloc(small_size) and memcpy(small_size) should be completely
independent of driver.
The cost of dma_unmap(mtu) , skb_alloc(mtu) & dma_map(mtu) determines the break
point. This operation should take less time for smaller mtu size,
and more time for larger mtu size. (especially for 9k mtu as we do not have
generic kmem_cache for size above 8192)
mtu of 9k is quite common for enic in data center. So rx_copybreak can go till
254. Most of the drivers use 100 as the copybreak, I guess thats because 1500
mtu is common for those nics and probably 100 is the break point.
Some driver allocates frags of pages, instead of contiguous memory.
I think it's better to leave the default to driver.
--
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
Powered by blists - more mailing lists