* Re: [PATCH net-next] be2net: fix truesize errors
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, sathya.perla, subbu.seetharaman, ajit.khaparde
In-Reply-To: <1318523553.2393.34.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 18:32:33 +0200
> Le jeudi 13 octobre 2011 à 18:31 +0200, Eric Dumazet a écrit :
>> Fix skb truesize underestimations of this driver.
>>
>> Each frag truesize is exactly rx_frag_size bytes. (2048 bytes per
>> default)
>>
>> A driver should not use "sizeof(struct sk_buff)" at all.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet>
>
> Oh well, garbled Signed-off-by, sorry !
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
:-) Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2: fix skb truesize underestimation
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, mchan
In-Reply-To: <1318528219.2393.52.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 19:50:19 +0200
> bnx2 allocates a full page per fragment. We must account PAGE_SIZE
> increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] e1000: fix skb truesize underestimation
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1318528422.2393.55.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 19:53:42 +0200
> e1000 allocates a full page per skb fragment. We must account PAGE_SIZE
> increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ixgbe: fix skb truesize underestimation
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1318528781.2393.59.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 19:59:41 +0200
> ixgbe allocates half a page per skb fragment. We must account
> PAGE_SIZE/2 increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] igb: fix skb truesize underestimation
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1318528601.2393.57.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 19:56:41 +0200
> e1000 allocates half a page per skb fragment. We must account
> PAGE_SIZE/2 increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] e1000e: fix skb truesize underestimation
From: David Miller @ 2011-10-13 20:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <1318529016.2393.62.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 20:03:36 +0200
> e1000e allocates a page per skb fragment. We must account
> PAGE_SIZE increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: David Miller @ 2011-10-13 20:08 UTC (permalink / raw)
To: glommer
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <4E9744A6.5010101@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Fri, 14 Oct 2011 00:05:58 +0400
> On 10/14/2011 12:00 AM, David Miller wrote:
>> That imposes a new non-trivial cost, in fast paths, even when people
>> do not use your feature.
> Well, there is a cost, but all past submissions included round trip
> benchmarks.
> In none of them I could see any significant slowdown.
Did you try millions of sockets doing all kinds of different accesses?
Did you check the nanosecond latency of operations over loopback so
that the real cost of you change can be isolated and thus measured
properly?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: David Miller @ 2011-10-13 20:12 UTC (permalink / raw)
To: glommer
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <4E9744A6.5010101@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Fri, 14 Oct 2011 00:05:58 +0400
> Also, I kind of dispute the affirmation that !cgroup will encompass
> the majority of users, since cgroups is being enabled by default by
> most vendors. All systemd based systems use it extensively, for
> instance.
I will definitely advise people against this, since the cost of having
this on by default is absolutely non-trivial.
People keep asking every few releases "where the heck has my performance
gone" and it's because of creeping features like this. This socket
cgroup feature is a prime example of where that kind of stuff comes
from.
I really get irritated when people go "oh, it's just one indirect
function call" and "oh, it's just one more pointer in struct sock"
We work really hard to _remove_ elements from structures and make them
smaller, and to remove expensive operations from the fast paths.
It might take someone weeks if not months to find a way to make a
patch which compensates for the extra overhead your patches are adding.
And I don't think you fully appreciate that.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: Glauber Costa @ 2011-10-13 20:14 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <20111013.161221.1969725742975317077.davem@davemloft.net>
On 10/14/2011 12:12 AM, David Miller wrote:
> From: Glauber Costa<glommer@parallels.com>
> Date: Fri, 14 Oct 2011 00:05:58 +0400
>
>> Also, I kind of dispute the affirmation that !cgroup will encompass
>> the majority of users, since cgroups is being enabled by default by
>> most vendors. All systemd based systems use it extensively, for
>> instance.
>
> I will definitely advise people against this, since the cost of having
> this on by default is absolutely non-trivial.
>
> People keep asking every few releases "where the heck has my performance
> gone" and it's because of creeping features like this. This socket
> cgroup feature is a prime example of where that kind of stuff comes
> from.
>
> I really get irritated when people go "oh, it's just one indirect
> function call" and "oh, it's just one more pointer in struct sock"
>
> We work really hard to _remove_ elements from structures and make them
> smaller, and to remove expensive operations from the fast paths.
>
> It might take someone weeks if not months to find a way to make a
> patch which compensates for the extra overhead your patches are adding.
>
> And I don't think you fully appreciate that.
Let's focus on this:
Are you happy, or at least willing to accept, an approach that keep
things as they were with cgroups *compiled out*, or were you referring
to not in use == compiled in, but with no users?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: David Miller @ 2011-10-13 20:16 UTC (permalink / raw)
To: glommer
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <4E9744A6.5010101@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Fri, 14 Oct 2011 00:05:58 +0400
> Thank you for letting me now about your view of this that early.
I depend upon my colleagues to assist me in the large task that is reviewing
the enormous number of networking patches that get submitted.
Unfortunately, none of them got a chance to review this patch set
seriously, since I know most of them (especially Eric Dumazet) would
balk at the overhead you're proposing to add to our stack, just as I
did.
This is the reality of the situation, and I'm sorry to tell you that
snippy retorts when someone does take the time out to review your work
won't help at all.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: can: the mailinglist moved to vger.kernel.org
From: Oliver Hartkopp @ 2011-10-13 20:17 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can, netdev
In-Reply-To: <1318506157-10329-1-git-send-email-mkl@pengutronix.de>
On 10/13/11 13:42, Marc Kleine-Budde wrote:
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
> ---
> MAINTAINERS | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index aac56f9..5008b08 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1671,7 +1671,7 @@ CAN NETWORK LAYER
> M: Oliver Hartkopp <socketcan@hartkopp.net>
> M: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
> M: Urs Thuermann <urs.thuermann@volkswagen.de>
> -L: socketcan-core@lists.berlios.de (subscribers-only)
> +L: linux-can@vger.kernel.org
> L: netdev@vger.kernel.org
> W: http://developer.berlios.de/projects/socketcan/
> S: Maintained
> @@ -1683,7 +1683,7 @@ F: include/linux/can/raw.h
>
> CAN NETWORK DRIVERS
> M: Wolfgang Grandegger <wg@grandegger.com>
> -L: socketcan-core@lists.berlios.de (subscribers-only)
> +L: linux-can@vger.kernel.org
> L: netdev@vger.kernel.org
> W: http://developer.berlios.de/projects/socketcan/
> S: Maintained
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: David Miller @ 2011-10-13 20:18 UTC (permalink / raw)
To: glommer
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <4E9746B0.7030603@parallels.com>
From: Glauber Costa <glommer@parallels.com>
Date: Fri, 14 Oct 2011 00:14:40 +0400
> Are you happy, or at least willing to accept, an approach that keep
> things as they were with cgroups *compiled out*, or were you referring
> to not in use == compiled in, but with no users?
To me these are the same exact thing, because %99 of users will be running
a kernel with every feature turned on in the Kconfig.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/8] Request for inclusion: tcp memory buffers
From: Glauber Costa @ 2011-10-13 20:23 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, akpm, lizf, kamezawa.hiroyu, ebiederm, paul,
gthelen, netdev, linux-mm, kirill, avagin, devel
In-Reply-To: <20111013.161608.1413756673453885746.davem@davemloft.net>
On 10/14/2011 12:16 AM, David Miller wrote:
> From: Glauber Costa<glommer@parallels.com>
> Date: Fri, 14 Oct 2011 00:05:58 +0400
>
>> Thank you for letting me now about your view of this that early.
>
> I depend upon my colleagues to assist me in the large task that is reviewing
> the enormous number of networking patches that get submitted.
>
> Unfortunately, none of them got a chance to review this patch set
> seriously, since I know most of them (especially Eric Dumazet) would
> balk at the overhead you're proposing to add to our stack, just as I
> did.
>
> This is the reality of the situation, and I'm sorry to tell you that
> snippy retorts when someone does take the time out to review your work
> won't help at all.
I understand that and appreciate your time.
I'll try to come up with something that addresses this problem in the
next submission.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next] net: more accurate skb truesize
From: Andi Kleen @ 2011-10-13 20:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1318519581.2393.18.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, Oct 13, 2011 at 05:26:21PM +0200, Eric Dumazet wrote:
> skb truesize currently accounts for sk_buff struct and part of skb head.
>
> Considering that skb_shared_info is larger than sk_buff, its time to
> take it into account for better memory accounting.
>
> This patch introduces SKB_TRUESIZE(X) macro to centralize various
> assumptions into a single place.
It's still quite inaccurate, especially for the kmalloced data area if it's not
paged. It would be better to ask slab how much memory was really
allocated. But at least this could be done more easily now with the new
macro, so it's definitely a step in the right direction.
-Andi
^ permalink raw reply
* Re: [net-next 1/5] stmmac: add CHAINED descriptor mode support (V2)
From: David Miller @ 2011-10-13 20:39 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev, rayagond
In-Reply-To: <1318426688-9419-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Wed, 12 Oct 2011 15:38:04 +0200
> +#if defined(CONFIG_STMMAC_RING)
> +
> +static unsigned int stmmac_jumbo_frm(struct stmmac_priv *priv,
> + struct sk_buff *skb, int csum_insertion)
> +{
This is not exactly what I meant.
In your original patch, two or three line snippets of code were conditionalized.
That's what I wanted you to do here. Keep as much common code around as possible
in the driver *.c file, but the small 2 or 3 line conditional parts are implemented
in very small well contained inline functions implemented in a header file.
These small, 2 or 3 line, inline functions are where the ifdefs go.
I didn't mean to replicate all of the functions, in their entirety, into some
header file.
You might was well put the entire driver into a header file, then you can add
all the ifdefs you want :-)
^ permalink raw reply
* Re: [PATCH net-next] net: more accurate skb truesize
From: Eric Dumazet @ 2011-10-13 20:51 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev
In-Reply-To: <20111013203352.GA5707@tassilo.jf.intel.com>
Le jeudi 13 octobre 2011 à 13:33 -0700, Andi Kleen a écrit :
> On Thu, Oct 13, 2011 at 05:26:21PM +0200, Eric Dumazet wrote:
> > skb truesize currently accounts for sk_buff struct and part of skb head.
> >
> > Considering that skb_shared_info is larger than sk_buff, its time to
> > take it into account for better memory accounting.
> >
> > This patch introduces SKB_TRUESIZE(X) macro to centralize various
> > assumptions into a single place.
>
> It's still quite inaccurate, especially for the kmalloced data area if it's not
> paged. It would be better to ask slab how much memory was really
> allocated. But at least this could be done more easily now with the new
> macro, so it's definitely a step in the right direction.
Note : in skb_alloc() function, SKB_TRUESIZE(size) delivers the exact
value : I do the ksize(data) call to ask how many byte kmalloc()
provided me.
So skb->truesize is quite accurate (unless KMEMCHECK or other debug
stuff is used of course)
For the SKB_TRUESIZE() macro, we dont want to do a dummy call to
kmalloc()/kfree(), since its basically used to roughly set a queue
limit.
Thanks !
^ permalink raw reply
* [PATCH net-next] sky2: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-13 21:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger
sky2 allocates a page per skb fragment. We must account
PAGE_SIZE increments on skb->truesize, not the actual frag length.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/ethernet/marvell/sky2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index 6895e3b..9263490 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -2486,7 +2486,7 @@ static void skb_put_frags(struct sk_buff *skb, unsigned int hdr_space,
frag->size = size;
skb->data_len += size;
- skb->truesize += size;
+ skb->truesize += PAGE_SIZE;
skb->len += size;
length -= size;
}
^ permalink raw reply related
* Re: [PATCH net-next] sky2: fix skb truesize underestimation
From: David Miller @ 2011-10-13 21:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, shemminger
In-Reply-To: <1318540290.2533.22.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 13 Oct 2011 23:11:30 +0200
> sky2 allocates a page per skb fragment. We must account
> PAGE_SIZE increments on skb->truesize, not the actual frag length.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH net-next] ftmac100: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-13 21:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Po-Yu Chuang
ftmac100 allocates a page per skb fragment. We must account
PAGE_SIZE increments on skb->truesize, not the actual frag length.
If frame is under 64 bytes, page is freed, so increase truesize only for
bigger frames.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Po-Yu Chuang <ratbert@faraday-tech.com>
---
drivers/net/ethernet/faraday/ftmac100.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
index 9bd7746..a127cb2 100644
--- a/drivers/net/ethernet/faraday/ftmac100.c
+++ b/drivers/net/ethernet/faraday/ftmac100.c
@@ -439,7 +439,10 @@ static bool ftmac100_rx_packet(struct ftmac100 *priv, int *processed)
skb_fill_page_desc(skb, 0, page, 0, length);
skb->len += length;
skb->data_len += length;
- skb->truesize += length;
+
+ /* page might be freed in __pskb_pull_tail() */
+ if (length > 64)
+ skb->truesize += PAGE_SIZE;
__pskb_pull_tail(skb, min(length, 64));
ftmac100_alloc_rx_page(priv, rxdes, GFP_ATOMIC);
^ permalink raw reply related
* [PATCH net-next] ftgmac100: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-13 21:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Po-Yu Chuang
ftgmac100 allocates a page per skb fragment. We must account
PAGE_SIZE increments on skb->truesize, not the actual frag length.
If frame is under 64 bytes, page is freed, and truesize adjusted.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Po-Yu Chuang <ratbert@faraday-tech.com>
---
drivers/net/ethernet/faraday/ftgmac100.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 54709af..fb5579a 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -467,7 +467,7 @@ static bool ftgmac100_rx_packet(struct ftgmac100 *priv, int *processed)
skb->len += size;
skb->data_len += size;
- skb->truesize += size;
+ skb->truesize += PAGE_SIZE;
if (ftgmac100_rxdes_last_segment(rxdes))
done = true;
@@ -478,6 +478,8 @@ static bool ftgmac100_rx_packet(struct ftgmac100 *priv, int *processed)
rxdes = ftgmac100_current_rxdes(priv);
} while (!done);
+ if (skb->len <= 64)
+ skb->truesize -= PAGE_SIZE;
__pskb_pull_tail(skb, min(skb->len, 64U));
skb->protocol = eth_type_trans(skb, netdev);
^ permalink raw reply related
* [PATCH net-next] vmxnet3: fix skb truesize underestimation
From: Eric Dumazet @ 2011-10-13 21:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Shreyas Bhatewara
vmxnet3 allocates a page per skb fragment. We must account
PAGE_SIZE increments on skb->truesize, not the actual frag length.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 1694038..902f284 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -658,6 +658,7 @@ vmxnet3_append_frag(struct sk_buff *skb, struct Vmxnet3_RxCompDesc *rcd,
frag->page_offset = 0;
frag->size = rcd->len;
skb->data_len += frag->size;
+ skb->truesize += PAGE_SIZE;
skb_shinfo(skb)->nr_frags++;
}
@@ -1277,7 +1278,6 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
skb = ctx->skb;
if (rcd->eop) {
skb->len += skb->data_len;
- skb->truesize += skb->data_len;
vmxnet3_rx_csum(adapter, skb,
(union Vmxnet3_GenericDesc *)rcd);
^ permalink raw reply related
* [PATCH 0/8] caif-hsi: Bug-fixes for CAIF HSI.
From: Sjur Brændeland @ 2011-10-13 21:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: dmitry.tarnyagin, daniel.martensson, Sjur Brændeland
This patch-set contains our latest pile of HSI bug fixes and
performance improvements for CAIF HSI driver.
Patches should apply cleanly on both net and net-next.
Regards,
Sjur
Daniel Martensson (4):
caif-hsi: Making read and writes asynchronous.
caif-hsi: HSI-Platform device register and unregisters itself
caif-hsi: Added sanity check for length of CAIF frames
caif-hsi: Added recovery check of CA wake status.
Dmitry Tarnyagin (3):
caif-hsi: Fixing a race condition in the caif_hsi code
caif-hsi: Fix for wakeup condition problem
caif-hsi: Make inactivity timeout configurable.
Sjur Brændeland (1):
caif-hsi: HSI Fix uninitialized data in HSI header
drivers/net/caif/caif_hsi.c | 427 +++++++++++++++++++++++++------------------
include/net/caif/caif_hsi.h | 37 +++-
2 files changed, 276 insertions(+), 188 deletions(-)
^ permalink raw reply
* [PATCH 1/8] caif-hsi: HSI Fix uninitialized data in HSI header
From: Sjur Brændeland @ 2011-10-13 21:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: dmitry.tarnyagin, daniel.martensson, Sjur Brændeland
In-Reply-To: <1318541369-8141-1-git-send-email-sjur.brandeland@stericsson.com>
CAIF HSI header may be uninitialized and cause last message to
be repeated if transmit size is ~86 bytes long.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
drivers/net/caif/caif_hsi.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 2fcabba..1937813 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -178,6 +178,9 @@ static int cfhsi_tx_frm(struct cfhsi_desc *desc, struct cfhsi *cfhsi)
if (!skb)
return 0;
+ /* Clear offset. */
+ desc->offset = 0;
+
/* Check if we can embed a CAIF frame. */
if (skb->len < CFHSI_MAX_EMB_FRM_SZ) {
struct caif_payload_info *info;
@@ -206,9 +209,7 @@ static int cfhsi_tx_frm(struct cfhsi_desc *desc, struct cfhsi *cfhsi)
consume_skb(skb);
skb = NULL;
}
- } else
- /* Clear offset. */
- desc->offset = 0;
+ }
/* Create payload CAIF frames. */
pfrm = desc->emb_frm + CFHSI_MAX_EMB_FRM_SZ;
@@ -990,6 +991,8 @@ int cfhsi_probe(struct platform_device *pdev)
/* Set up the driver. */
cfhsi->drv.tx_done_cb = cfhsi_tx_done_cb;
cfhsi->drv.rx_done_cb = cfhsi_rx_done_cb;
+ cfhsi->drv.wake_up_cb = cfhsi_wake_up_cb;
+ cfhsi->drv.wake_down_cb = cfhsi_wake_down_cb;
/* Initialize the work queues. */
INIT_WORK(&cfhsi->wake_up_work, cfhsi_wake_up);
@@ -1045,9 +1048,6 @@ int cfhsi_probe(struct platform_device *pdev)
goto err_net_reg;
}
- cfhsi->drv.wake_up_cb = cfhsi_wake_up_cb;
- cfhsi->drv.wake_down_cb = cfhsi_wake_down_cb;
-
/* Register network device. */
res = register_netdev(ndev);
if (res) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/8] caif-hsi: Fixing a race condition in the caif_hsi code
From: Sjur Brændeland @ 2011-10-13 21:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: dmitry.tarnyagin, daniel.martensson, Sjur Brændeland
In-Reply-To: <1318541369-8141-1-git-send-email-sjur.brandeland@stericsson.com>
From: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
cfhsi->tx_state was not protected by a spin lock. TX soft-irq could interrupt
cfhsi_tx_done_work work leading to inconsistent state of the driver.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
drivers/net/caif/caif_hsi.c | 25 ++++++++++++++++++-------
1 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 1937813..36da27b 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -304,14 +304,22 @@ static void cfhsi_tx_done_work(struct work_struct *work)
spin_unlock_bh(&cfhsi->lock);
/* Create HSI frame. */
- len = cfhsi_tx_frm(desc, cfhsi);
- if (!len) {
- cfhsi->tx_state = CFHSI_TX_STATE_IDLE;
- /* Start inactivity timer. */
- mod_timer(&cfhsi->timer,
+ do {
+ len = cfhsi_tx_frm(desc, cfhsi);
+ if (!len) {
+ spin_lock_bh(&cfhsi->lock);
+ if (unlikely(skb_peek(&cfhsi->qhead))) {
+ spin_unlock_bh(&cfhsi->lock);
+ continue;
+ }
+ cfhsi->tx_state = CFHSI_TX_STATE_IDLE;
+ /* Start inactivity timer. */
+ mod_timer(&cfhsi->timer,
jiffies + CFHSI_INACTIVITY_TOUT);
- break;
- }
+ spin_unlock_bh(&cfhsi->lock);
+ goto done;
+ }
+ } while (!len);
/* Set up new transfer. */
res = cfhsi->dev->cfhsi_tx(cfhsi->tx_buf, len, cfhsi->dev);
@@ -320,6 +328,9 @@ static void cfhsi_tx_done_work(struct work_struct *work)
__func__, res);
}
} while (res < 0);
+
+done:
+ return;
}
static void cfhsi_tx_done_cb(struct cfhsi_drv *drv)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/8] caif-hsi: Fix for wakeup condition problem
From: Sjur Brændeland @ 2011-10-13 21:29 UTC (permalink / raw)
To: David Miller, netdev
Cc: dmitry.tarnyagin, daniel.martensson, Sjur Brændeland
In-Reply-To: <1318541369-8141-1-git-send-email-sjur.brandeland@stericsson.com>
From: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
Under stressed conditions a race could happen when del_timer_sync() was called
from softirq context at the same time when mod_timer_pending() for the same
timer was called from the workqueue. This leaded to a state mismatch in the
CAIF HSI driver and following unexpected link wakeup procedure.
The fix puts del_timer_sync() and mod_timer_pending() calls under a spin lock
to protect against the race condition.
Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
---
drivers/net/caif/caif_hsi.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 36da27b..82c4d6c 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -551,7 +551,9 @@ static void cfhsi_rx_done_work(struct work_struct *work)
return;
/* Update inactivity timer if pending. */
+ spin_lock_bh(&cfhsi->lock);
mod_timer_pending(&cfhsi->timer, jiffies + CFHSI_INACTIVITY_TOUT);
+ spin_unlock_bh(&cfhsi->lock);
if (cfhsi->rx_state == CFHSI_RX_STATE_DESC) {
desc_pld_len = cfhsi_rx_desc(desc, cfhsi);
@@ -866,10 +868,10 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
start_xfer = 1;
}
- spin_unlock_bh(&cfhsi->lock);
-
- if (!start_xfer)
+ if (!start_xfer) {
+ spin_unlock_bh(&cfhsi->lock);
return 0;
+ }
/* Delete inactivity timer if started. */
#ifdef CONFIG_SMP
@@ -878,6 +880,8 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
timer_active = del_timer(&cfhsi->timer);
#endif /* CONFIG_SMP */
+ spin_unlock_bh(&cfhsi->lock);
+
if (timer_active) {
struct cfhsi_desc *desc = (struct cfhsi_desc *)cfhsi->tx_buf;
int len;
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox