* Re: [PATCH net-next] myri10ge: fix truesize underestimation
From: Andrew Gallatin @ 2011-10-20 20:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jon Mason, David Miller, netdev
In-Reply-To: <1319143442.2854.26.camel@edumazet-laptop>
On 10/20/11 16:44, Eric Dumazet wrote:
> Le jeudi 20 octobre 2011 à 15:33 -0500, Jon Mason a écrit :
>> On Thu, Oct 20, 2011 at 3:10 PM, Eric Dumazet<eric.dumazet@gmail.com> wrote:
>>> skb->truesize must account for allocated memory, not the used part of
>>> it. Doing this work is important to avoid unexpected OOM situations.
>>>
>>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>>
>> Acked-by: Jon Mason<mason@myri.com>
>
> Thanks for reviewing Jon !
>
>
Please wait a second.. I think the patch is incorrect.
There is already code in myri10ge_rx_skb_build() which
attempts to set the truesize. However, it sets it to
the used, rather than the allocated size so it is apparently
incorrect.
I'd prefer we fix that code.
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH net-next] myri10ge: fix truesize underestimation
From: Eric Dumazet @ 2011-10-20 20:44 UTC (permalink / raw)
To: Jon Mason; +Cc: David Miller, netdev, Andrew Gallatin
In-Reply-To: <CAMaF-rN8K3hDiwwqh_eGQ0nrxskn+7r9Rn_yDJ46aesKR77nbg@mail.gmail.com>
Le jeudi 20 octobre 2011 à 15:33 -0500, Jon Mason a écrit :
> On Thu, Oct 20, 2011 at 3:10 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > skb->truesize must account for allocated memory, not the used part of
> > it. Doing this work is important to avoid unexpected OOM situations.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Jon Mason <mason@myri.com>
Thanks for reviewing Jon !
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering support for passthru mode
From: Rose, Gregory V @ 2011-10-20 20:43 UTC (permalink / raw)
To: Roopa Prabhu, netdev@vger.kernel.org
Cc: sri@us.ibm.com, dragos.tatulea@gmail.com, arnd@arndb.de,
kvm@vger.kernel.org, mst@redhat.com, davem@davemloft.net,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <CAC49D8A.374FB%roprabhu@cisco.com>
> -----Original Message-----
> From: Roopa Prabhu [mailto:roprabhu@cisco.com]
> Sent: Wednesday, October 19, 2011 3:30 PM
> To: Rose, Gregory V; netdev@vger.kernel.org
> Cc: sri@us.ibm.com; dragos.tatulea@gmail.com; arnd@arndb.de;
> kvm@vger.kernel.org; mst@redhat.com; davem@davemloft.net;
> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com
> Subject: Re: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address
> filtering support for passthru mode
>
>
>
>
> On 10/19/11 2:06 PM, "Rose, Gregory V" <gregory.v.rose@intel.com> wrote:
>
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org]
> >> On Behalf Of Roopa Prabhu
> >> Sent: Tuesday, October 18, 2011 11:26 PM
> >> To: netdev@vger.kernel.org
> >> Cc: sri@us.ibm.com; dragos.tatulea@gmail.com; arnd@arndb.de;
> >> kvm@vger.kernel.org; mst@redhat.com; davem@davemloft.net;
> >> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
> >> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com
> >> Subject: [net-next-2.6 PATCH 0/8 RFC v2] macvlan: MAC Address filtering
> >> support for passthru mode
> >>
> >
> > [snip...]
> >
> >>
> >>
> >> Note: The choice of rtnl_link_ops was because I saw the use case for
> >> this in virtual devices that need to do filtering in sw like macvlan
> >> and tun. Hw devices usually have filtering in hw with netdev->uc and
> >> mc lists to indicate active filters. But I can move from rtnl_link_ops
> >> to netdev_ops if that is the preferred way to go and if there is a
> >> need to support this interface on all kinds of interfaces.
> >> Please suggest.
> >
> > I'm still digesting the rest of the RFC patches but I did want to
> quickly jump
> > in and push for adding this support in netdev_ops. I would like to see
> these
> > features available in more devices than just macvtap and macvlan. I can
> > conceive
> > of use cases for multiple HW MAC and VLAN filters for a VF device that
> isn't
> > owned by a macvlan/macvtap interface and only has netdev_ops support.
> In this
> > case it would be necessary to program the filters directly to the VF
> device
> > interface or PF interface (or lowerdev as you refer to it) instead of
> going
> > through macvlan/macvtap.
> >
> > This work dovetails nicely with some work I've been doing and I'd be
> very
> > interested
> > in helping move this forward if we could work out the details that would
> allow
> > support
> > of the features we (and the community) require.
>
> Great. Thanks. I will definitely be interested to get this patch working
> for
> any other use case you have.
>
> Moving the ops to netdev should be trivial. You probably want the ops to
> work on the VF via the PF, like the existing ndo_set_vf_mac etc.
That is correct, so we would need to add some way to pass the VF number to the op.
In addition, there are use cases for multiple MAC address filters for the Physical
Function (PF) so we would like to be able to identify to the netdev op that it is
supposed to perform the action on the PF filters instead of a VF.
An example of this would be when an administrator has created some number of VFs
for a given PF but is also running the PF in bridged (i.e. promiscuous) mode so that it
can support purely SW emulated network connections in some VMs that have low network
latency and bandwidth requirements while reserving the VFs for VMs that require the low latency, high throughput that directly assigned VFs can provide. In this case an
emulated SW interface in a VM is unable to properly communicate with VFs on the same
PF because the emulated SW interface's MAC address isn't programmed into the HW filters
on the PF. If we could use this op to program the MAC address and VLAN filters of
the emulated SW interfaces into the PF HW a VF could then properly communicate across
the NIC's internal VEB to the emulated SW interfaces.
> Yes, lets work out the details and I can move this to netdev->ops. Let me
> know.
I think essentially if you could add some parameter to the ops to specify whether it
is addressing a VF or the PF and then if it is a VF further specify the VF number we
would be very close to addressing the requirements of many valuable use cases in
addition to the ones you have identified in your RFC.
Does that sound reasonable?
Thanks,
- Greg
^ permalink raw reply
* [PATCH v2 net-next] tcp: use TCP_DEFAULT_INIT_RCVWND in tcp_fixup_rcvbuf()
From: Eric Dumazet @ 2011-10-20 20:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111020.161356.2120784879469409197.davem@davemloft.net>
Since commit 356f039822b (TCP: increase default initial receive
window.), we allow sender to send 10 (TCP_DEFAULT_INIT_RCVWND) segments.
Change tcp_fixup_rcvbuf() to reflect this change, even if no real change
is expected, since sysctl_tcp_rmem[1] = 87380 and this value
is bigger than tcp_fixup_rcvbuf() computed rcvmem (~23720)
Note: Since commit 356f039822b limited default window to maximum of
10*1460 and 2*MSS, we use same heuristic in this patch.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_input.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1e848b2..e8e6d49 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -345,17 +345,24 @@ static void tcp_grow_window(struct sock *sk, struct sk_buff *skb)
static void tcp_fixup_rcvbuf(struct sock *sk)
{
- struct tcp_sock *tp = tcp_sk(sk);
- int rcvmem = SKB_TRUESIZE(tp->advmss + MAX_TCP_HEADER);
+ u32 mss = tcp_sk(sk)->advmss;
+ u32 icwnd = TCP_DEFAULT_INIT_RCVWND;
+ int rcvmem;
- /* Try to select rcvbuf so that 4 mss-sized segments
- * will fit to window and corresponding skbs will fit to our rcvbuf.
- * (was 3; 4 is minimum to allow fast retransmit to work.)
+ /* Limit to 10 segments if mss <= 1460,
+ * or 14600/mss segments, with a minimum of two segments.
*/
- while (tcp_win_from_space(rcvmem) < tp->advmss)
+ if (mss > 1460)
+ icwnd = max_t(u32, (1460 * TCP_DEFAULT_INIT_RCVWND) / mss, 2);
+
+ rcvmem = SKB_TRUESIZE(mss + MAX_TCP_HEADER);
+ while (tcp_win_from_space(rcvmem) < mss)
rcvmem += 128;
- if (sk->sk_rcvbuf < 4 * rcvmem)
- sk->sk_rcvbuf = min(4 * rcvmem, sysctl_tcp_rmem[2]);
+
+ rcvmem *= icwnd;
+
+ if (sk->sk_rcvbuf < rcvmem)
+ sk->sk_rcvbuf = min(rcvmem, sysctl_tcp_rmem[2]);
}
/* 4. Try to fixup all. It is made immediately after connection enters
^ permalink raw reply related
* Re: Kernel panic from tg3 net driver
From: Ari Savolainen @ 2011-10-20 20:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, richardcochran, netdev, linux-kernel
In-Reply-To: <1319141867.2854.19.camel@edumazet-laptop>
That's right. I tried the patch and it didn't help.
Ari
2011/10/20 Eric Dumazet <eric.dumazet@gmail.com>:
> Le jeudi 20 octobre 2011 à 16:11 -0400, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 20 Oct 2011 22:05:25 +0200
>>
>> > And I think this was fixed yesterday ?
>> >
>> > De: roy.qing.li@gmail.com
>> > À: ari.m.savolainen@gmail.com, netdev@vger.kernel.org
>> > Sujet: [PATCH net-next] neigh: fix rcu splat in neigh_update()
>> > Date: Tue, 18 Oct 2011 16:32:42 +0800 (18/10/2011 10:32:42)
>> >
>>
>> Good catch, it seems to be this bug.
>
> Oh well, sorry, it seems it was one bug hit during bisection, but maybe
> its completely unrelated to the real problem.
>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] myri10ge: fix truesize underestimation
From: Jon Mason @ 2011-10-20 20:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Andrew Gallatin
In-Reply-To: <1319141403.2854.17.camel@edumazet-laptop>
On Thu, Oct 20, 2011 at 3:10 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> skb->truesize must account for allocated memory, not the used part of
> it. Doing this work is important to avoid unexpected OOM situations.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Jon Mason <mason@myri.com>
> CC: Jon Mason <mason@myri.com>
> ---
> drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> index c970a48..0778edc 100644
> --- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> +++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
> @@ -1210,7 +1210,6 @@ myri10ge_rx_skb_build(struct sk_buff *skb, u8 * va,
> struct skb_frag_struct *skb_frags;
>
> skb->len = skb->data_len = len;
> - skb->truesize = len + sizeof(struct sk_buff);
> /* attach the page(s) */
>
> skb_frags = skb_shinfo(skb)->frags;
> @@ -1385,6 +1384,8 @@ myri10ge_rx_done(struct myri10ge_slice_state *ss, int len, __wsum csum,
> if (skb_frag_size(&skb_shinfo(skb)->frags[0]) <= 0) {
> skb_frag_unref(skb, 0);
> skb_shinfo(skb)->nr_frags = 0;
> + } else {
> + skb->truesize += bytes * skb_shinfo(skb)->nr_frags;
> }
> skb->protocol = eth_type_trans(skb, dev);
> skb_record_rx_queue(skb, ss - &mgp->ss[0]);
>
>
>
^ permalink raw reply
* Re: [patch net-next]alx: Atheros AR8131/AR8151/AR8152/AR8161 Ethernet driver
From: Luis R. Rodriguez @ 2011-10-20 20:33 UTC (permalink / raw)
To: Ren, Cloud
Cc: David Miller, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6349D7A510622448B1BA0967850A8438011CC2A0@nasanexd02d.na.qualcomm.com>
On Thu, Oct 20, 2011 at 2:48 AM, Ren, Cloud <cjren@qca.qualcomm.com> wrote:
>
>>From: "Ren, Cloud" <cjren@qca.qualcomm.com>
>>Date: Thu, 20 Oct 2011 09:23:07 +0000
>>
>>> As you saw, should I do the two following steps?
>>> 1. I firstly try to submit code to linux-staging.git.
>>> 2. After the driver have been accepted by linux-staging.git, I submit to net-
>>next.git again.
>>
>>You submit and get it into staging so that it can sit there for some time and get
>>reviewed and improved by others.
>>
>>One doesn't submit directly to net-next right after it gets into staging, staging
>>is a place where your driver lives while it still smelly funky and needs more
>>work.
>
> The driver will support the next generation NICs of Atheros. Meanwhile, the driver can
> also have better optimization for AR8131 and AR8151 than atl1c. For some reason, we
> don't plan to patch atl1c driver to support our new NIC, such as AR8161. So I hope the driver
> can stay in net-next in the end. Of course, I will be responsible for modify source code and
> let it match kernel requirements.
Cloud,
If you want to skip staging (which I recommend) then you need to
address all upstream concerns expressed. Given that you indicate that
you will be working on following up with the driver until its
acceptable upstream my recommendation is either to clean up the driver
very well and review it internally at Atheros prior to a public
submission *or* just dump into staging and get the benefit of
community cleanup and eventually wait until it is ready for proper
upstream. If you want internal private review at Atheros you can use
the internal private ath9k-devel list.
Also are you going to maintain the older atlx drivers? While at it can
you clear up who maintains what as far as Atheros is concerned for
Ethernet?
Luis
^ permalink raw reply
* Re: [patch] pktgen: bug when calling ndelay in x86 architectures
From: David Miller @ 2011-10-20 20:24 UTC (permalink / raw)
To: eric.dumazet
Cc: bhutchings, daniel.turull, netdev, robert, voravit, jens.laas
In-Reply-To: <1318949264.2657.97.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 18 Oct 2011 16:47:44 +0200
> Le mardi 18 octobre 2011 à 15:00 +0100, Ben Hutchings a écrit :
>
>> AIUI, the reason for limits on delays is not that it's bad practice to
>> spin for so long, but that the delay calculations may overflow or
>> otherwise become inaccurate.
>
> OK, I can understand that, then a more appropriate patch would be :
I think doing the udelay/ndelay thing is the way to go for 'net' and
-stable. We can do something sophisticated with ktime et al. in
'net-next'.
Eric, could you please formally submit this patch with proper
changelog etc.?
Thanks.
^ permalink raw reply
* Re: PROBLEM: System call 'sendmsg' of process ospfd (quagga) causes kernel oops
From: David Miller @ 2011-10-20 20:21 UTC (permalink / raw)
To: herbert; +Cc: eric.dumazet, evonlanthen, linux-kernel, netdev, timo.teras
In-Reply-To: <20111020093541.GA3024@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Thu, 20 Oct 2011 11:35:41 +0200
> On Thu, Oct 20, 2011 at 05:30:50AM -0400, David Miller wrote:
>>
>> So I'm a little confused what your suggestion for rc10 really
>> is :-)
>
> I meant his first initial patch :)
>
> While it is suboptimal in the sense that should the value of
> needed_headroom increase we'll end up constantly reallocating
> skbs, I believe that it is at least semantically correct.
Ok, I applied Eric's patch which removes the dynamic changing of the
needed_headroom in IP_GRE.
Thanks everyone!
^ permalink raw reply
* Re: [PATCH] route: fix ICMP redirect validation
From: David Miller @ 2011-10-20 20:19 UTC (permalink / raw)
To: fbl; +Cc: netdev
In-Reply-To: <20111020154702.13f69021@asterix.rh>
From: Flavio Leitner <fbl@redhat.com>
Date: Thu, 20 Oct 2011 15:47:02 -0200
> I was reviewing this again and instead of doing the above, it would
> be better to use rt_bind_peer() to update rt->peer as well.
>
> if (!rt->peer)
> rt_bind_peer(rt, rt->rt_dst, 1);
>
> peer = rt->peer;
> if (peer) {
> peer->redirect_learned.a4 = new_gw;
> atomic_inc(&__rt_peer_genid);
> }
>
>
> but I am not sure if I understood you completely when you say
> to do such that only an inetpeer cache probe is necessary.
If you have the route entry available already and you're doing the
inetpeer lookup anyways, you might as well use rt_bind_peer() since
all of the expensive work has to be done anyways.
So yes, using rt_bind_peer() would be the best thing to do here.
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: Eric Dumazet @ 2011-10-20 20:17 UTC (permalink / raw)
To: David Miller; +Cc: ari.m.savolainen, richardcochran, netdev, linux-kernel
In-Reply-To: <20111020.161147.33259825921677777.davem@davemloft.net>
Le jeudi 20 octobre 2011 à 16:11 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 20 Oct 2011 22:05:25 +0200
>
> > And I think this was fixed yesterday ?
> >
> > De: roy.qing.li@gmail.com
> > À: ari.m.savolainen@gmail.com, netdev@vger.kernel.org
> > Sujet: [PATCH net-next] neigh: fix rcu splat in neigh_update()
> > Date: Tue, 18 Oct 2011 16:32:42 +0800 (18/10/2011 10:32:42)
> >
>
> Good catch, it seems to be this bug.
Oh well, sorry, it seems it was one bug hit during bisection, but maybe
its completely unrelated to the real problem.
^ permalink raw reply
* Re: [PATCH] dev: use name hash for dev_seq_ops
From: David Miller @ 2011-10-20 20:17 UTC (permalink / raw)
To: mihai.maruseac
Cc: shemminger, eric.dumazet, mirq-linux, therbert, jpirko, netdev,
linux-kernel, dbaluta, mmaruseac
In-Reply-To: <1319097717-14910-1-git-send-email-mmaruseac@ixiacom.com>
From: Mihai Maruseac <mihai.maruseac@gmail.com>
Date: Thu, 20 Oct 2011 11:01:57 +0300
> Instead of using the dev->next chain and trying to resync at each call to
> dev_seq_start, use the name hash, keeping the bucket and the offset in
> seq->private field.
I'm totally fine with this patch from a technical perspective, but I'd
like one small thing tidied up before I apply this.
> + unsigned int pos; /* bucket << 24 + offset */
Please don't mention this as a constant in the comment, if we ever
change NETDEV_HASHBITS this comment will be inaccurate.
I'd suggest putting the BUCKET_SPACE define before the dev_iter_state
definition, and using BUCKET_SPACE in the comment instead of 24.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: use TCP_DEFAULT_INIT_RCVWND in tcp_fixup_rcvbuf()
From: David Miller @ 2011-10-20 20:13 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1319140954.2854.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Oct 2011 22:02:34 +0200
> Le jeudi 20 octobre 2011 à 15:50 -0400, David Miller a écrit :
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 20 Oct 2011 21:16:26 +0200
>>
>> > Since commit 356f039822b (TCP: increase default initial receive
>> > window.), we allow sender to send 10 (TCP_DEFAULT_INIT_RCVWND) segments.
>> >
>> > Change tcp_fixup_rcvbuf() to reflect this change, even if no real change
>> > is expected, since sysctl_tcp_rmem[1] = 87380 and this value
>> > is bigger than tcp_fixup_rcvbuf() computed rcvmem (~23720)
>> >
>> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> ...
>> > + unsigned int mss = min_t(unsigned int, tp->advmss, 1460);
>>
>> I don't understand where this calculation comes from, and even if it
>> should be obvious it isn't to me and deserves a mention in the commit
>> message at a minimum.
>
> This is the calculation done in commit 356f039822b as well.
>
> The window is 10*MSS, but no more than 14600
>
> On loopback, this matters, because we could end with rcvmem=219680
Thanks, please help weak brains like mine by adding this to the commit message.
:-)
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: David Miller @ 2011-10-20 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: ari.m.savolainen, richardcochran, netdev, linux-kernel
In-Reply-To: <1319141125.2854.14.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Oct 2011 22:05:25 +0200
> And I think this was fixed yesterday ?
>
> De: roy.qing.li@gmail.com
> À: ari.m.savolainen@gmail.com, netdev@vger.kernel.org
> Sujet: [PATCH net-next] neigh: fix rcu splat in neigh_update()
> Date: Tue, 18 Oct 2011 16:32:42 +0800 (18/10/2011 10:32:42)
>
Good catch, it seems to be this bug.
^ permalink raw reply
* [PATCH net-next] myri10ge: fix truesize underestimation
From: Eric Dumazet @ 2011-10-20 20:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jon Mason
skb->truesize must account for allocated memory, not the used part of
it. Doing this work is important to avoid unexpected OOM situations.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Jon Mason <mason@myri.com>
---
drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
index c970a48..0778edc 100644
--- a/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
+++ b/drivers/net/ethernet/myricom/myri10ge/myri10ge.c
@@ -1210,7 +1210,6 @@ myri10ge_rx_skb_build(struct sk_buff *skb, u8 * va,
struct skb_frag_struct *skb_frags;
skb->len = skb->data_len = len;
- skb->truesize = len + sizeof(struct sk_buff);
/* attach the page(s) */
skb_frags = skb_shinfo(skb)->frags;
@@ -1385,6 +1384,8 @@ myri10ge_rx_done(struct myri10ge_slice_state *ss, int len, __wsum csum,
if (skb_frag_size(&skb_shinfo(skb)->frags[0]) <= 0) {
skb_frag_unref(skb, 0);
skb_shinfo(skb)->nr_frags = 0;
+ } else {
+ skb->truesize += bytes * skb_shinfo(skb)->nr_frags;
}
skb->protocol = eth_type_trans(skb, dev);
skb_record_rx_queue(skb, ss - &mgp->ss[0]);
^ permalink raw reply related
* Re: Kernel panic from tg3 net driver
From: Eric Dumazet @ 2011-10-20 20:05 UTC (permalink / raw)
To: David Miller; +Cc: ari.m.savolainen, richardcochran, netdev, linux-kernel
In-Reply-To: <20111020.155659.486754557434415381.davem@davemloft.net>
Le jeudi 20 octobre 2011 à 15:56 -0400, David Miller a écrit :
> From: Ari Savolainen <ari.m.savolainen@gmail.com>
> Date: Thu, 20 Oct 2011 22:30:44 +0300
>
> > I finally got time to continue bisecting. The commit that causes the
> > kernel panic is: 2669069aacc9 "tg3: enable transmit time stamping."
>
> I thought initially that the issue might be that we have to do the
> skb_tx_timestamp() call before we advance the mailbox transmit
> descriptor pointer.
>
> But that shouldn't matter, we run with a lock held, and TX reclaim takes
> that same lock.
>
> So I'm sort of stumped at the moment.
But its not a panic, its a RCU splat ?
> [ 105.612129] [<ffffffff810ccdcb>] lockdep_rcu_dereference+0xbb/0xc0
> [ 105.612132] [<ffffffff815dc5a9>] neigh_update+0x4f9/0x5f0
> [ 105.612135] [<ffffffff815da001>] ? neigh_lookup+0xe1/0x220
> [ 105.612139] [<ffffffff81639298>] arp_req_set+0xb8/0x230
> [ 105.612142] [<ffffffff8163a59f>] arp_ioctl+0x1bf/0x310
> [ 105.612146] [<ffffffff810baa40>] ? lock_hrtimer_base.isra.26+0x30/0x60
> [ 105.612150] [<ffffffff8163fb75>] inet_ioctl+0x85/0x90
> [ 105.612154] [<ffffffff815b5520>] sock_do_ioctl+0x30/0x70
> [ 105.612157] [<ffffffff815b55d3>] sock_ioctl+0x73/0x280
> [ 105.612162] [<ffffffff811b7698>] do_vfs_ioctl+0x98/0x570
> [ 105.612165] [<ffffffff811a5c40>] ? fget_light+0x340/0x3a0
> [ 105.612168] [<ffffffff811b7bbf>] sys_ioctl+0x4f/0x80
> [ 105.612172] [<ffffffff816fdcab>] system_call_fastpath+0x16/0x1b
And I think this was fixed yesterday ?
De: roy.qing.li@gmail.com
À: ari.m.savolainen@gmail.com, netdev@vger.kernel.org
Sujet: [PATCH net-next] neigh: fix rcu splat in neigh_update()
Date: Tue, 18 Oct 2011 16:32:42 +0800 (18/10/2011 10:32:42)
^ permalink raw reply
* Re: [PATCH net-next] tcp: use TCP_DEFAULT_INIT_RCVWND in tcp_fixup_rcvbuf()
From: Eric Dumazet @ 2011-10-20 20:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20111020.155002.555965434596006787.davem@davemloft.net>
Le jeudi 20 octobre 2011 à 15:50 -0400, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 20 Oct 2011 21:16:26 +0200
>
> > Since commit 356f039822b (TCP: increase default initial receive
> > window.), we allow sender to send 10 (TCP_DEFAULT_INIT_RCVWND) segments.
> >
> > Change tcp_fixup_rcvbuf() to reflect this change, even if no real change
> > is expected, since sysctl_tcp_rmem[1] = 87380 and this value
> > is bigger than tcp_fixup_rcvbuf() computed rcvmem (~23720)
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ...
> > + unsigned int mss = min_t(unsigned int, tp->advmss, 1460);
>
> I don't understand where this calculation comes from, and even if it
> should be obvious it isn't to me and deserves a mention in the commit
> message at a minimum.
This is the calculation done in commit 356f039822b as well.
The window is 10*MSS, but no more than 14600
On loopback, this matters, because we could end with rcvmem=219680
^ permalink raw reply
* RE: [net-next 5/6] ixgbe: add hardware timestamping support
From: Keller, Jacob E @ 2011-10-20 19:57 UTC (permalink / raw)
To: Richard Cochran, Jacob Keller
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20111020145637.GC1949@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: Thursday, October 20, 2011 7:57 AM
> To: Jacob Keller
> Cc: Kirsher, Jeffrey T; davem@davemloft.net; Keller, Jacob E;
> netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com
> Subject: Re: [net-next 5/6] ixgbe: add hardware timestamping support
>
> On Wed, Oct 19, 2011 at 10:04:33AM -0700, Jacob Keller wrote:
> > On Mon, Oct 17, 2011 at 9:44 AM, Richard Cochran
> <richardcochran@gmail.com> wrote:
> > > So, is this wrap around due to the fact that you are tied to the
> > > system time via time_compare? Or, putting it another way, can't you
> > > program the hardware time stamping unit so that the registers have
> > > some reasonable resolution (like 64 bits worth of nanoseconds) and
> > > just offer RAW timestamps?
> >
> > The wrap around is due to hardware limitations. The ixgbe devices
> > cannot support 64bits worth of nanoseconds and still have the ability
> > to adjust the frequency in parts per billion. A larger increment
> > increases the resolution available for frequency adjustments, but
> > decreases the time it takes for the cycle counter to wrap around.
>
> Oh, well. That stinks.
>
> I think you do want to offer ppb adjustment.
>
Correct, which is why the cycle counter wraps around every 35 seconds.
> > > I would really like to move away from the timecompare hacks and
> > > towards a proper PHC->SYS PPS solution.
> > >
> >
> > I agree that this is the correct approach. The timecompare
> > functionality does have issues.
>
> And these cards are highlighting timecompare weaknesses I had not even
> thought of.
>
> I expect that if you offer the RAW time stamps, then it should be
> possible to have the time stamp values always correct (or nearly so)
> even with a changing link speed. If the link speed change gives an
> interrupt, then the ISR can reprogram the frequency compensation
> registers and let the counter continue.
>
The cyclecounter is based off of the DMA clock on the NIC which changes frequency with the link speed. So at 10G link, the DMA ticks once every 6.4ns. The cycle counter gets a value (specified in the TIMINCA register) added to it every DMA tick. In order to allow for ppb adjustments to the cycle counter, I have the TIMINCA value be as many bits wide as possible. Then I use the cyclecounter/timecounter structures to detect wraparound and convert to a ns value.
If we return the raw cycle counter stamps directly, they would not be measured in nanoseconds, but in a division of the DMA clock tick (DMA clock tick / TIMINCA value). This means for the values I chose we are somewhere in the range of femto seconds or so. The problem is that all of the upper stack expects values as nanoseconds. We wouldn't be able to frequency adjust in ppb to get down to nanoseconds again.
This is due to a limitation in the way the hardware was designed, (Ideally it would allow for precise adjustments, but still provide a nanosecond counter. The 82580 igb device does this.)
> > > Again, doing the update thing on every packet won't work for real
> > > world PTP scenarios.
> > >
> > Which is why the PHC solution is better. Work on implementing this
> > support is in progress. Out of curiosity, what is the sync rate for
> > the scenario that breaks this? I would like to try that rate out on
> my
> > setup.
>
> For the audio/video profile, they have a max of 32 sync packets per
> second. Not sure about delay request rate, maybe 16 per second.
>
Thanks :)
> Thanks,
> Richard
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: David Miller @ 2011-10-20 19:56 UTC (permalink / raw)
To: ari.m.savolainen; +Cc: richardcochran, netdev, linux-kernel
In-Reply-To: <CAEbykaX4UPDBxOHmNr=dodaquSPjhPr-pLCcUn5hSu4-xLZy-g@mail.gmail.com>
From: Ari Savolainen <ari.m.savolainen@gmail.com>
Date: Thu, 20 Oct 2011 22:30:44 +0300
> I finally got time to continue bisecting. The commit that causes the
> kernel panic is: 2669069aacc9 "tg3: enable transmit time stamping."
I thought initially that the issue might be that we have to do the
skb_tx_timestamp() call before we advance the mailbox transmit
descriptor pointer.
But that shouldn't matter, we run with a lock held, and TX reclaim takes
that same lock.
So I'm sort of stumped at the moment.
^ permalink raw reply
* Re: [PATCH net-next] tcp: use TCP_DEFAULT_INIT_RCVWND in tcp_fixup_rcvbuf()
From: David Miller @ 2011-10-20 19:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1319138186.2854.5.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Oct 2011 21:16:26 +0200
> Since commit 356f039822b (TCP: increase default initial receive
> window.), we allow sender to send 10 (TCP_DEFAULT_INIT_RCVWND) segments.
>
> Change tcp_fixup_rcvbuf() to reflect this change, even if no real change
> is expected, since sysctl_tcp_rmem[1] = 87380 and this value
> is bigger than tcp_fixup_rcvbuf() computed rcvmem (~23720)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
...
> + unsigned int mss = min_t(unsigned int, tp->advmss, 1460);
I don't understand where this calculation comes from, and even if it
should be obvious it isn't to me and deserves a mention in the commit
message at a minimum.
^ permalink raw reply
* Re: Kernel panic from tg3 net driver
From: Ari Savolainen @ 2011-10-20 19:30 UTC (permalink / raw)
To: David S. Miller, Richard Cochran, netdev, linux-kernel
In-Reply-To: <CAEbykaXz+J8abVzU3yjqZG2+yhHNrQWsQy2c8wNyoERWPpxWKQ@mail.gmail.com>
I finally got time to continue bisecting. The commit that causes the
kernel panic is: 2669069aacc9 "tg3: enable transmit time stamping."
Ari
2011/10/15 Ari Savolainen <ari.m.savolainen@gmail.com>:
> Hi,
>
> I get this panic when I try to print from a virtual machine:
>
> https://docs.google.com/leaf?id=0B7LPWLwa6EUaODIxYTY2YmQtNWJlZS00M2ViLTk5ZmEtNDM2ZTZmNzE2MDEz&hl=fi
>
> I tried to bisect it, but couldn't finish, because after the last step
> the boot process got stuck right after selecting the kernel in grub
> and I ran out of time:
>
> git bisect start
> # bad: [322a8b034003c0d46d39af85bf24fee27b902f48] Linux 3.1-rc1
> git bisect bad 322a8b034003c0d46d39af85bf24fee27b902f48
> # good: [02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] Linux 3.0
> git bisect good 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe
> # bad: [0003230e8200699860f0b10af524dc47bf8aecad] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6
> git bisect bad 0003230e8200699860f0b10af524dc47bf8aecad
> # bad: [72f96e0e38d7e29ba16dcfd824ecaebe38b8293e] Merge branch
> 'for-linus-core' of
> git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
> git bisect bad 72f96e0e38d7e29ba16dcfd824ecaebe38b8293e
> # good: [204d1641d200709c759d8c269458cbc7de378c40] Merge branch
> 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
> into for-davem
> git bisect good 204d1641d200709c759d8c269458cbc7de378c40
> # bad: [415b3334a21aa67806c52d1acf4e72e14f7f402f] icmp: Fix regression
> in nexthop resolution during replies.
> git bisect bad 415b3334a21aa67806c52d1acf4e72e14f7f402f
> # bad: [95a943c162d74b20d869917bdf5df11293c35b63] Merge branch
> 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
> into for-davem
> git bisect bad 95a943c162d74b20d869917bdf5df11293c35b63
>
> In the first bad kernel (3.1-rc1) there was this in the log:
>
> [ 105.612095]
> [ 105.612096] ===================================================
> [ 105.612100] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 105.612101] ---------------------------------------------------
> [ 105.612103] include/net/dst.h:91 invoked rcu_dereference_check()
> without protection!
> [ 105.612105]
> [ 105.612106] other info that might help us debug this:
> [ 105.612106]
> [ 105.612108]
> [ 105.612108] rcu_scheduler_active = 1, debug_locks = 0
> [ 105.612110] 1 lock held by dnsmasq/2618:
> [ 105.612111] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff815df8c7>]
> rtnl_lock+0x17/0x20
> [ 105.612120]
> [ 105.612121] stack backtrace:
> [ 105.612123] Pid: 2618, comm: dnsmasq Not tainted 3.1.0-rc1 #41
> [ 105.612125] Call Trace:
> [ 105.612129] [<ffffffff810ccdcb>] lockdep_rcu_dereference+0xbb/0xc0
> [ 105.612132] [<ffffffff815dc5a9>] neigh_update+0x4f9/0x5f0
> [ 105.612135] [<ffffffff815da001>] ? neigh_lookup+0xe1/0x220
> [ 105.612139] [<ffffffff81639298>] arp_req_set+0xb8/0x230
> [ 105.612142] [<ffffffff8163a59f>] arp_ioctl+0x1bf/0x310
> [ 105.612146] [<ffffffff810baa40>] ? lock_hrtimer_base.isra.26+0x30/0x60
> [ 105.612150] [<ffffffff8163fb75>] inet_ioctl+0x85/0x90
> [ 105.612154] [<ffffffff815b5520>] sock_do_ioctl+0x30/0x70
> [ 105.612157] [<ffffffff815b55d3>] sock_ioctl+0x73/0x280
> [ 105.612162] [<ffffffff811b7698>] do_vfs_ioctl+0x98/0x570
> [ 105.612165] [<ffffffff811a5c40>] ? fget_light+0x340/0x3a0
> [ 105.612168] [<ffffffff811b7bbf>] sys_ioctl+0x4f/0x80
> [ 105.612172] [<ffffffff816fdcab>] system_call_fastpath+0x16/0x1b
>
^ permalink raw reply
* [PATCH net-next] igbvf: fix truesize underestimation
From: Eric Dumazet @ 2011-10-20 19:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jeff Kirsher
igbvf 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>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 1bd9abd..db29817 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -312,7 +312,7 @@ static bool igbvf_clean_rx_irq(struct igbvf_adapter *adapter,
skb->len += length;
skb->data_len += length;
- skb->truesize += length;
+ skb->truesize += PAGE_SIZE / 2;
}
send_up:
i++;
^ permalink raw reply related
* [PATCH net-next] tcp: use TCP_DEFAULT_INIT_RCVWND in tcp_fixup_rcvbuf()
From: Eric Dumazet @ 2011-10-20 19:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Since commit 356f039822b (TCP: increase default initial receive
window.), we allow sender to send 10 (TCP_DEFAULT_INIT_RCVWND) segments.
Change tcp_fixup_rcvbuf() to reflect this change, even if no real change
is expected, since sysctl_tcp_rmem[1] = 87380 and this value
is bigger than tcp_fixup_rcvbuf() computed rcvmem (~23720)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_input.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1e848b2..5a29ecc 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -345,17 +345,15 @@ static void tcp_grow_window(struct sock *sk, struct sk_buff *skb)
static void tcp_fixup_rcvbuf(struct sock *sk)
{
- struct tcp_sock *tp = tcp_sk(sk);
- int rcvmem = SKB_TRUESIZE(tp->advmss + MAX_TCP_HEADER);
+ const struct tcp_sock *tp = tcp_sk(sk);
+ unsigned int mss = min_t(unsigned int, tp->advmss, 1460);
+ int rcvmem = SKB_TRUESIZE(mss + MAX_TCP_HEADER);
- /* Try to select rcvbuf so that 4 mss-sized segments
- * will fit to window and corresponding skbs will fit to our rcvbuf.
- * (was 3; 4 is minimum to allow fast retransmit to work.)
- */
- while (tcp_win_from_space(rcvmem) < tp->advmss)
+ while (tcp_win_from_space(rcvmem) < mss)
rcvmem += 128;
- if (sk->sk_rcvbuf < 4 * rcvmem)
- sk->sk_rcvbuf = min(4 * rcvmem, sysctl_tcp_rmem[2]);
+ rcvmem *= TCP_DEFAULT_INIT_RCVWND;
+ if (sk->sk_rcvbuf < rcvmem)
+ sk->sk_rcvbuf = min(rcvmem, sysctl_tcp_rmem[2]);
}
/* 4. Try to fixup all. It is made immediately after connection enters
^ permalink raw reply related
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: Michał Mirosław @ 2011-10-20 18:57 UTC (permalink / raw)
To: wwguy
Cc: Intel Linux Wireless, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20111014192105.GA23640@rere.qmqm.pl>
On Fri, Oct 14, 2011 at 09:21:05PM +0200, Michał Mirosław wrote:
> On Fri, Oct 14, 2011 at 08:29:18AM -0700, wwguy wrote:
> > Could you try the attach patch and see if it fix your problem.
> [attached patch removed]
> Backported and applied. I'll test it for couple of days.
I haven't tripped on the warnings in those last days with your
patch applied. I think the backported version should be included
in 3.1.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: iwlagn: WARN_ON() in iwl_get_idle_rx_chain_count()
From: wwguy @ 2011-10-20 18:54 UTC (permalink / raw)
To: Michał Mirosław
Cc: Intel Linux Wireless,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20111020185756.GA24185-CoA6ZxLDdyEEUmgCuDUIdw@public.gmane.org>
On Thu, 2011-10-20 at 11:57 -0700, Michał Mirosław wrote:
> On Fri, Oct 14, 2011 at 09:21:05PM +0200, Michał Mirosław wrote:
> > On Fri, Oct 14, 2011 at 08:29:18AM -0700, wwguy wrote:
> > > Could you try the attach patch and see if it fix your problem.
> > [attached patch removed]
> > Backported and applied. I'll test it for couple of days.
>
> I haven't tripped on the warnings in those last days with your
> patch applied. I think the backported version should be included
> in 3.1.
>
Thank you for testing it, I will push it upstream into 3.1
Best Regards
Wey
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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