From: Eric Dumazet [mailto:eric.duma...@gmail.com]
Sent: 03 July 2015 17:39
On Fri, 2015-07-03 at 16:18 +, David Laight wrote:
Even on x86 aligning the ethernet receive data on a 4n+2
boundary is likely to give marginally better performance
than aligning on a 4n boundary.
You are
From: Eric Dumazet
Sent: 01 July 2015 23:14
To: Joe Perches
...
Then please use netdev_alloc_skb_ip_align(), so that you get rid of
skb_reserve()
It seems there are ~50 of these in the kernel tree
that could be converted.
Make sure the 2 is really NET_IP_ALIGN
Some hardwares
On Fri, 2015-07-03 at 16:18 +, David Laight wrote:
Even on x86 aligning the ethernet receive data on a 4n+2
boundary is likely to give marginally better performance
than aligning on a 4n boundary.
You are coming late to the party.
Intel guys decided to change NET_IP_ALIGN to 0 (it was 2
On Wed, 2015-07-01 at 12:56 +0200, Eric Dumazet wrote:
On Tue, 2015-06-30 at 20:25 +0300, Nicolae Rosia wrote:
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
[]
@@ -2554,9 +2554,9 @@ static void at91ether_rx(struct net_device *dev)
while
On 07/01/2015 04:44 PM, Eric Dumazet wrote:
I really doubt this adapter can process millions of packets per second ?
I was suggesting this since I was taking into consideration the comment
from skbuff.c, we can save several CPU cycles by avoiding having to
disable and re-enable IRQs.
Is there
On 07/01/2015 01:56 PM, Eric Dumazet wrote:
Then please use netdev_alloc_skb_ip_align(), so that you get rid of
skb_reserve()
Thank you for the suggestion.
I can do that.
A related question, should I also replace netdev_alloc with
napi_alloc_skb in places where I have a napi struct?
--
To
On Wed, 2015-07-01 at 16:29 +0300, Nicolae Rosia wrote:
On 07/01/2015 01:56 PM, Eric Dumazet wrote:
Then please use netdev_alloc_skb_ip_align(), so that you get rid of
skb_reserve()
Thank you for the suggestion.
I can do that.
A related question, should I also replace netdev_alloc with
Le 30/06/2015 19:25, Nicolae Rosia a écrit :
Signed-off-by: Nicolae Rosia nicolae.ro...@certsign.ro
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks, bye.
---
drivers/net/ethernet/cadence/macb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, 2015-06-30 at 20:25 +0300, Nicolae Rosia wrote:
Signed-off-by: Nicolae Rosia nicolae.ro...@certsign.ro
---
drivers/net/ethernet/cadence/macb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
On Wed, Jul 1, 2015 at 6:33 PM, Eric Dumazet eric.duma...@gmail.com wrote:
[...]
This only matters in terms of few nano seconds per packet, so for 10Gb+
NIC anyway. Absolute noise for most NIC.
I'll give it a try and benchmark.
I achieved a huge speedup by moving TX into napi [0], but my
On Wed, 2015-07-01 at 17:29 +0300, Nicolae Rosia wrote:
On 07/01/2015 04:44 PM, Eric Dumazet wrote:
I really doubt this adapter can process millions of packets per second ?
I was suggesting this since I was taking into consideration the comment
from skbuff.c, we can save several CPU cycles
On Wed, 2015-07-01 at 18:53 +0300, Nicolae Rosia wrote:
On Wed, Jul 1, 2015 at 6:33 PM, Eric Dumazet eric.duma...@gmail.com wrote:
[...]
This only matters in terms of few nano seconds per packet, so for 10Gb+
NIC anyway. Absolute noise for most NIC.
I'll give it a try and benchmark.
I
On Wed, 2015-07-01 at 10:06 -0700, Joe Perches wrote:
On Wed, 2015-07-01 at 12:56 +0200, Eric Dumazet wrote:
On Tue, 2015-06-30 at 20:25 +0300, Nicolae Rosia wrote:
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
[]
@@ -2554,9 +2554,9 @@ static
On Thu, 2015-07-02 at 00:13 +0200, Eric Dumazet wrote:
On Wed, 2015-07-01 at 10:06 -0700, Joe Perches wrote:
On Wed, 2015-07-01 at 12:56 +0200, Eric Dumazet wrote:
On Tue, 2015-06-30 at 20:25 +0300, Nicolae Rosia wrote:
diff --git a/drivers/net/ethernet/cadence/macb.c
14 matches
Mail list logo
