From: David Brownell [mailto:davi...@pacbell.net]
Sent: Monday, April 13, 2009 10:28 PM
Isn't the issue that NET_IP_ALIGN is supposed to resolve,
when properly used by network drivers?
Looking at the documentation for that macro, drivers are supposed
to call skb_reserve() with
From: Troy Kisky [mailto:troy.ki...@boundarydevices.com]
Sent: Saturday, April 11, 2009 7:17 AM
nsek...@ti.com wrote:
From: Steve Chen [sc...@mvista.com]
[...]
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 635e31f..eecd983 100644
---
On Friday 10 April 2009, nsek...@ti.com wrote:
This issue is resolved by using a 2-byte extra offset in the packet buffer.
Isn't the issue that NET_IP_ALIGN is supposed to resolve,
when properly used by network drivers?
___
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Monday, April 13, 2009 8:43 PM
On Friday 10 April 2009, nsek...@ti.com wrote:
This issue is resolved by using a 2-byte extra offset in the packet
buffer.
Isn't the issue that NET_IP_ALIGN is supposed to resolve,
when properly used by
Isn't the issue that NET_IP_ALIGN is supposed to resolve,
when properly used by network drivers?
Looking at the documentation for that macro, drivers are supposed
to call skb_reserve() with NET_IP_ALIGN as argument. The patch is
doing the same, just not using the macro NET_IP_ALIGN.
From: Steve Chen [sc...@mvista.com]
The skb data allocated for packet data received is 4 byte aligned.
Unfortunately, this causes non-32bit aligned accesses in IP stack because
the MAC header is non-word aligned (14 bytes).
The result can be observed by looking at /proc/cpu/alignment while the
nsek...@ti.com wrote:
From: Steve Chen [sc...@mvista.com]
The skb data allocated for packet data received is 4 byte aligned.
Unfortunately, this causes non-32bit aligned accesses in IP stack because
the MAC header is non-word aligned (14 bytes).
The result can be observed by looking at
