From: Li Yang le...@freescale.com
Date: Fri, 20 Mar 2009 17:04:29 +0800
The bridging device used a constant hard_header_len. This will cause
headroom shortage for ports with additional hardware header. The patch
makes bridging device to use the maximum value of all ports.
Signed-off-by:
On Wed, Mar 25, 2009 at 2:40 PM, David Miller da...@davemloft.net wrote:
From: Li Yang le...@freescale.com
Date: Fri, 20 Mar 2009 17:04:29 +0800
The bridging device used a constant hard_header_len. This will cause
headroom shortage for ports with additional hardware header. The patch
makes
From: Li Yang le...@freescale.com
Date: Wed, 25 Mar 2009 15:05:20 +0800
On Wed, Mar 25, 2009 at 2:40 PM, David Miller da...@davemloft.net wrote:
From: Li Yang le...@freescale.com
Date: Fri, 20 Mar 2009 17:04:29 +0800
The bridging device used a constant hard_header_len. This will cause
On Wed, Mar 25, 2009 at 3:06 PM, David Miller da...@davemloft.net wrote:
From: Li Yang le...@freescale.com
Date: Wed, 25 Mar 2009 15:05:20 +0800
On Wed, Mar 25, 2009 at 2:40 PM, David Miller da...@davemloft.net wrote:
From: Li Yang le...@freescale.com
Date: Fri, 20 Mar 2009 17:04:29 +0800
On Tue, Mar 24, 2009 at 6:20 AM, David Miller da...@davemloft.net wrote:
From: Stephen Hemminger shemmin...@linux-foundation.org
Date: Mon, 23 Mar 2009 08:51:22 -0700
That ensures big enough header for locally generated packets, but
any drivers that need bigger headroom still must handle
From: Li Yang le...@freescale.com
Date: Wed, 25 Mar 2009 16:43:53 +0800
Dynamically adjusting is a good idea, but the rx_alloc_extra can only
go up not the other way down in your code.
That's not a problem.
Another thought is that if you re-allocate skb here the driver would
be saved from
On Fri, Mar 20, 2009 at 5:04 PM, Li Yang le...@freescale.com wrote:
The bridging device used a constant hard_header_len. This will cause
headroom shortage for ports with additional hardware header. The patch
makes bridging device to use the maximum value of all ports.
Signed-off-by: Li Yang
From: Li Yang le...@freescale.com
Date: Mon, 23 Mar 2009 16:15:34 +0800
I was wondering if this one failed to get your attention.
yeah, happens all the time
___
Bridge mailing list
Bridge@lists.linux-foundation.org
On Fri, 20 Mar 2009 17:04:29 +0800
Li Yang le...@freescale.com wrote:
The bridging device used a constant hard_header_len. This will cause
headroom shortage for ports with additional hardware header. The patch
makes bridging device to use the maximum value of all ports.
Signed-off-by: Li
From: Stephen Hemminger shemmin...@linux-foundation.org
Date: Mon, 23 Mar 2009 08:51:22 -0700
That ensures big enough header for locally generated packets, but
any drivers that need bigger headroom still must handle bridged packets
that come in with smaller space. When bridging packets, the
On Mon, 23 Mar 2009 15:20:28 -0700 (PDT)
David Miller da...@davemloft.net wrote:
From: Stephen Hemminger shemmin...@linux-foundation.org
Date: Mon, 23 Mar 2009 08:51:22 -0700
That ensures big enough header for locally generated packets, but
any drivers that need bigger headroom still must
From: Stephen Hemminger shemmin...@linux-foundation.org
Date: Mon, 23 Mar 2009 15:45:17 -0700
So you dynamically compute the additional space but if the space was
an awkward size, could it cause driver to breaks alignment assumptions?
Yes, you'd need to 16-byte align or something like that.
The bridging device used a constant hard_header_len. This will cause
headroom shortage for ports with additional hardware header. The patch
makes bridging device to use the maximum value of all ports.
Signed-off-by: Li Yang le...@freescale.com
---
Fixes the following BUG when using bridging
13 matches
Mail list logo
