* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-21 8:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, netdev, e1000-devel, jeffrey.t.kirsher,
jesse.brandeburg, davem
In-Reply-To: <1337572583.3361.8.camel@edumazet-glaptop>
On 2012-05-21 06:56, Eric Dumazet wrote:
> On Sun, 2012-05-20 at 22:18 +0300, Denys Fedoryshchenko wrote:
>> On 2012-05-20 22:07, Eric Dumazet wrote:
>> >
>> > You could try latencytop, I am not sure if some obvious things
>> will
>> > popup.
>> For sure i did. Nothing unusual here, max 5ms latency
>> Cause Maximum
>> Percentage
>> [__skb_recv_datagram] 4.1 msec
>
> Interesting
>
> So your workload is a mix of pings, and receive.
>
> Problem is softirq handler might use a lot of time to complete the
> receives, because of TCP stack complexity. And BQL use softirq to
> restart the transmits on the same cpu.
>
> tcp_data_queue() can copy the received data directly to user space.
> (taking page faults...)
>
> Could you check if net-next behaves the same ?
Not sure it is a lot of time, after all it is 2 x core quad machine,
should be enough fast for pings.
It will cause stalls on small packets even more seems.
Tested latest git, net-next, still the same, stalls.
hardware latency detector are silent by the way, so there is no
significant SMI.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH] drivers/net/stmmac: seq_file fix memory leak
From: David Miller @ 2012-05-21 7:38 UTC (permalink / raw)
To: tixxdz; +Cc: peppe.cavallaro, netdev
In-Reply-To: <20120520235530.GA22698@dztty>
From: Djalal Harouni <tixxdz@opendz.org>
Date: Mon, 21 May 2012 00:55:30 +0100
> Use single_release() instead of seq_release() to free memory allocated
> by single_open().
>
> Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] TIPC: Stepping TIPC version to 2.1.0
From: David Miller @ 2012-05-21 6:40 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy
In-Reply-To: <1337579954-17161-3-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:14 -0400
> Catch-up with out-of-tree version is done. We can go ahead
> with more development.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Again, I don't trust you, you and the windriver folks have haven't
submitted upstream TIPC patches for year, therefore I'd rather someone
I have an ongoing relation with, such as Paul, submit this stuff.
You can't ignore and write off upstream TIPC completely, then show up
out of the blue and start being the main source of changes. That's
rude, and I simply won't allow that.
^ permalink raw reply
* Re: [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: David Miller @ 2012-05-21 6:39 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy
In-Reply-To: <1337579954-17161-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:12 -0400
> With the latest series of patches from Paul Gortmaker and Allan
> Stephens TIPC is now functionally mature and stable enough to
> justify removal of the EXPERIMENTAL label.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
I'll let Paul Gortmaker decide whether this is warranted or
not.
I don't really want to all of a sudden start seeing patches from
people like you and the windriver folks, who effectively wrote off
upstream and left poor Paul Gortmaker holding the bag and having to
take care of EVERYTHING.
You can't just do nothing for years, end up making someone else
do it, then say "Hey here I am, I feel like submitting upstream
patches now" after I've spent this entire time starting to trust
Paul for TIPC patches.
^ permalink raw reply
* Re: [PATCH 2/3] TIPC: Adding new developers to maintainers list
From: David Miller @ 2012-05-21 6:37 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy
In-Reply-To: <1337579954-17161-2-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 21 May 2012 01:59:13 -0400
> Adding two very welcome new developers to maintainers list.
> They have both worked with TIPC development for a while,
> and are now ready to submit their own patches to net-next.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Continuing to add windriver people to the maintainers list
is a bit of a joke don't you think?
No windriver person has submitted directly any of the hundreds
of patches that poor Paul Gortmaker had to backport and take
care of.
He is effectively the sole and only maintainer as far as I am
concerned.
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the net-next tree
From: Stephen Rothwell @ 2012-05-21 6:28 UTC (permalink / raw)
To: Kalle Valo
Cc: Greg KH, linux-next, linux-kernel, Sarah Sharp, David Miller,
netdev, John W. Linville
In-Reply-To: <4FB9DDD9.8000506@qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
Hi Kalle,
On Mon, 21 May 2012 09:16:57 +0300 Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>
> Is there anything I should do in ath6kl to handle the issue?
No, Linus will take care of it when he merges the two trees.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the net-next tree
From: Kalle Valo @ 2012-05-21 6:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Sarah Sharp, David Miller,
netdev, John W. Linville
In-Reply-To: <20120521161008.c0cc00b91642ed7a3875a686@canb.auug.org.au>
On 05/21/2012 09:10 AM, Stephen Rothwell wrote:
> Today's linux-next merge of the usb tree got a conflict in
> drivers/net/wireless/ath/ath6kl/usb.c between commit 9cbee358687e
> ("ath6kl: add full USB support") from the net-next tree and commit
> e1f12eb6ba6f ("USB: Disable hub-initiated LPM for comms devices") from
> the usb tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Is there anything I should do in ath6kl to handle the issue?
Kalle
^ permalink raw reply
* Re: [V2 PATCH 2/9] macvtap: zerocopy: fix truesize underestimation
From: Jason Wang @ 2012-05-21 6:15 UTC (permalink / raw)
To: Shirley Ma; +Cc: eric.dumazet, mst, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <1337354551.12999.6.camel@oc3660625478.ibm.com>
On 05/18/2012 11:22 PM, Shirley Ma wrote:
> On Fri, 2012-05-18 at 18:10 +0800, Jason Wang wrote:
>>> On Thu, 2012-05-17 at 10:59 +0800, Jason Wang wrote:
>>>> Didn't see how this affact skb->len. And for truesize, I think they
>>>> are
>>>> different, when the offset were not zero, the data in this vector
>>>> were
>>>> divided into two parts. First part is copied into skb directly, and
>>>> the
>>>> second were pinned from a whole userspace page by
>>>> get_user_pages_fast(),
>>>> so we need count the whole page to the socket limit to prevent evil
>>>> application.
>>> What I meant that the code for skb->truesize has double added the
>> first
>>> offset if any left from that vector (partically copied into skb
>>> directly, and then count pagesize which includes the offset
>> (truesize +=
>>> PAGE_SIZE)).
>> Yes, I get you mean. There's no difference between first frag and
>> others: it's also possible for other frags that didn't occupy the
>> whole
>> page. Since we pin the whole user page, better to count the whole
>> page
>> size to prevent evil application.
> The difference between first frags and others is other frags might not
> occupy the whole page, but the first frags extra offset was doubled
> added in skb truesize.
>
> So it's ok for skb->truesize to be bigger than all the skb pinned pages
> here?
I think it's ok here and we could find other example such as virtio_net
driver.
>
> Thanks
> Shirley
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the usb tree with the net-next tree
From: Stephen Rothwell @ 2012-05-21 6:10 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Sarah Sharp, Kalle Valo, David Miller,
netdev, John W. Linville
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/net/wireless/ath/ath6kl/usb.c between commit 9cbee358687e
("ath6kl: add full USB support") from the net-next tree and commit
e1f12eb6ba6f ("USB: Disable hub-initiated LPM for comms devices") from
the usb tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/ath/ath6kl/usb.c
index dfbbe9e,f8a27db..0000000
--- a/drivers/net/wireless/ath/ath6kl/usb.c
+++ b/drivers/net/wireless/ath/ath6kl/usb.c
@@@ -1185,12 -403,9 +1185,13 @@@ MODULE_DEVICE_TABLE(usb, ath6kl_usb_ids
static struct usb_driver ath6kl_usb_driver = {
.name = "ath6kl_usb",
.probe = ath6kl_usb_probe,
+ .suspend = ath6kl_usb_suspend,
+ .resume = ath6kl_usb_resume,
+ .reset_resume = ath6kl_usb_reset_resume,
.disconnect = ath6kl_usb_remove,
.id_table = ath6kl_usb_ids,
+ .supports_autosuspend = true,
+ .disable_hub_initiated_lpm = 1,
};
static int ath6kl_usb_init(void)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/3] TIPC: Adding new developers to maintainers list
From: Jon Maloy @ 2012-05-21 5:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy, Jon Maloy
In-Reply-To: <1337579954-17161-1-git-send-email-jon.maloy@ericsson.com>
Adding two very welcome new developers to maintainers list.
They have both worked with TIPC development for a while,
and are now ready to submit their own patches to net-next.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 490dd6e..6f0aec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6683,7 +6683,9 @@ F: include/linux/wl12xx.h
TIPC NETWORK LAYER
M: Jon Maloy <jon.maloy@ericsson.com>
+M: Erik Hugne <erik.hugne@ericsson.com>
M: Allan Stephens <allan.stephens@windriver.com>
+M: Ying Xue <ying.xue@windriver.com>
L: netdev@vger.kernel.org (core kernel code)
L: tipc-discussion@lists.sourceforge.net (user apps, general discussion)
W: http://tipc.sourceforge.net/
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] TIPC: Removing EXPERIMENTAL label
From: Jon Maloy @ 2012-05-21 5:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy, Jon Maloy
With the latest series of patches from Paul Gortmaker and Allan
Stephens TIPC is now functionally mature and stable enough to
justify removal of the EXPERIMENTAL label.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/Kconfig b/net/tipc/Kconfig
index 2c5954b..fdc1625 100644
--- a/net/tipc/Kconfig
+++ b/net/tipc/Kconfig
@@ -3,8 +3,8 @@
#
menuconfig TIPC
- tristate "The TIPC Protocol (EXPERIMENTAL)"
- depends on INET && EXPERIMENTAL
+ tristate "The TIPC Protocol"
+ depends on INET
---help---
The Transparent Inter Process Communication (TIPC) protocol is
specially designed for intra cluster communication. This protocol
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] TIPC: Stepping TIPC version to 2.1.0
From: Jon Maloy @ 2012-05-21 5:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy, Jon Maloy
In-Reply-To: <1337579954-17161-1-git-send-email-jon.maloy@ericsson.com>
Catch-up with out-of-tree version is done. We can go ahead
with more development.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/core.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/core.h b/net/tipc/core.h
index 2a9bb99..3ab29bf 100644
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
@@ -1,7 +1,7 @@
/*
* net/tipc/core.h: Include file for TIPC global declarations
*
- * Copyright (c) 2005-2006, Ericsson AB
+ * Copyright (c) 2005-2006, 2012, Ericsson AB
* Copyright (c) 2005-2007, 2010-2011, Wind River Systems
* All rights reserved.
*
@@ -56,7 +56,7 @@
#include <linux/vmalloc.h>
-#define TIPC_MOD_VER "2.0.0"
+#define TIPC_MOD_VER "2.1.0"
struct tipc_msg; /* msg.h */
struct print_buf; /* log.h */
--
1.7.9.5
^ permalink raw reply related
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Jason Wang @ 2012-05-21 6:05 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, eric.dumazet, netdev, linux-kernel, ebiederm,
davem
In-Reply-To: <1337354974.12999.12.camel@oc3660625478.ibm.com>
On 05/18/2012 11:29 PM, Shirley Ma wrote:
> On Fri, 2012-05-18 at 17:58 +0800, Jason Wang wrote:
>> On 05/17/2012 11:34 PM, Shirley Ma wrote:
>>> On Thu, 2012-05-17 at 10:50 +0800, Jason Wang wrote:
>>>> The problem is we may stop the tx queue when there no enough
>> capacity
>>>> to
>>>> place packets, at this moment we depends on the tx interrupt to
>>>> re-enable the tx queue. So if we didn't poll the vhost during
>>>> callback,
>>>> guest may lose the tx interrupt to re-enable the tx queue which
>> could
>>>> stall the whole tx queue.
>>> VHOST_MAX_PEND should handle the capacity.
>>>
>>> Hasn't the above situation been handled in handle_tx() code?:
>>> ...
>>> if (unlikely(num_pends> VHOST_MAX_PEND)) {
>>> tx_poll_start(net, sock);
>>>
>> set_bit(SOCK_ASYNC_NOSPACE,&sock->flags);
>>> break;
>>> }
>>> ...
>>>
>>> Thanks
>>> Shirley
>> It may not help in because:
>>
>> - tx polling depends on skb_orphan() which is often called by device
>> driver when it place the packet into the queue of the devices instead
>> of when the packets were sent. So it was too early for vhost to be
>> notified.
> Then do you think it's better to replace with vhost_poll_queue here
> instead?
Just like what does this patch do - calling vhost_poll_queue() in
vhost_zerocopy_callback().
>> - it only works when the pending DMAs exceeds VHOST_MAX_PEND, it's
>> highly possible that guest needs to be notified when the pending
>> packets
>> isn't so much.
> In which situation the guest needs to be notified when there is no TX
> besides buffers run out?
Consider guest call virtqueue_enable_cb_delayed() which means it only
need to be notified when 3/4 of pending buffers ( about 178 buffers
(256-MAX_SKB_FRAGS-2)*3/4 ) were sent by host. So vhost_net would notify
guest when about 60 buffers were pending. Since tx polling is only
enabled when pending packets exceeds VHOST_MAX_PEND 128, so tx work
would not be notified to run and guest would never get the interrupt it
expected to re-enable the queue.
And just like what we've discussed, tx polling based adding and
signaling is too early for vhost.
>> So this piece of code may not help and could be removed and we need
>> to
>> poll the virt-queue during zerocopy callback ( through it could be
>> further optimized but may not be easy).
> Thanks
> Shirley
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv6: use skb coalescing in reassembly
From: Eric Dumazet @ 2012-05-21 5:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, alexander.h.duyck
In-Reply-To: <20120519.183556.1085711138074171029.davem@davemloft.net>
On Sat, 2012-05-19 at 18:35 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 19 May 2012 15:02:35 +0200
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > ip6_frag_reasm() can use skb_try_coalesce() to build optimized skb,
> > reducing memory used by them (truesize), and reducing number of cache
> > line misses and overhead for the consumer.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Applied.
I'll do the same for net/ipv6/netfilter/nf_conntrack_reasm.c today.
Thanks
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Jason Wang @ 2012-05-21 5:22 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, eric.dumazet, netdev, linux-kernel, ebiederm,
davem
In-Reply-To: <1337195303.10741.37.camel@oc3660625478.ibm.com>
On 05/17/2012 03:08 AM, Shirley Ma wrote:
> On Wed, 2012-05-16 at 21:36 +0300, Michael S. Tsirkin wrote:
>> On Wed, May 16, 2012 at 10:32:05AM -0700, Shirley Ma wrote:
>>> On Wed, 2012-05-16 at 18:14 +0300, Michael S. Tsirkin wrote:
>>>> On Wed, May 16, 2012 at 08:10:27AM -0700, Shirley Ma wrote:
>>>>> On Wed, 2012-05-16 at 10:58 +0800, Jason Wang wrote:
>>>>>>>> drivers/vhost/vhost.c | 1 +
>>>>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>>>>>>>> index 947f00d..7b75fdf 100644
>>>>>>>> --- a/drivers/vhost/vhost.c
>>>>>>>> +++ b/drivers/vhost/vhost.c
>>>>>>>> @@ -1604,6 +1604,7 @@ void vhost_zerocopy_callback(void
>> *arg)
>>>>>>>> struct vhost_ubuf_ref *ubufs = ubuf->arg;
>>>>>>>> struct vhost_virtqueue *vq = ubufs->vq;
>>>>>>>>
>>>>>>>> + vhost_poll_queue(&vq->poll);
>>>>>>>> /* set len = 1 to mark this desc buffers done DMA
>> */
>>>>>>>> vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN;
>>>>>>>> kref_put(&ubufs->kref,
>> vhost_zerocopy_done_signal);
>>>>>>> Doing so, we might have redundant vhost_poll_queue(). Do you
>>>> know in
>>>>>>> which scenario there might be missing of adding and
>> signaling
>>>> during
>>>>>>> zerocopy?
>>>>>> Yes, as we only do signaling and adding during tx work, if
>> there's
>>>> no
>>>>>> tx
>>>>>> work when the skb were sent, we may lose the opportunity to
>> let
>>>> guest
>>>>>> know about the completion. It's easy to be reproduced with
>> netperf
>>>>>> test.
>>>>> The reason which host signals guest is to free guest tx buffers,
>> if
>>>>> there is no tx work, then it's not necessary to signal the guest
>>>> unless
>>>>> guest runs out of memory. The pending buffers will be released
>>>>> virtio_net device gone.
>>>>>
>>>>> What's the behavior of netperf test when you hit this situation?
>>>>>
>>>>> Thanks
>>>>> Shirley
>>>> IIRC guest networking seems to be lost.
>>> It seems vhost_enable_notify is missing in somewhere else?
>>>
>>> Thanks
>>> Shirley
>> Donnu. I see virtio sending packets but they do not get
>> to tun on host. debugging.
> I looked at the code, if (zerocopy) check is needed for below code:
>
> + if (zerocopy) {
> num_pends = likely(vq->upend_idx>= vq->done_idx) ?
> (vq->upend_idx - vq->done_idx) :
> (vq->upend_idx + UIO_MAXIOV - vq->done_idx);
> if (unlikely(num_pends> VHOST_MAX_PEND)) {
> tx_poll_start(net, sock);
> vhost_poll_queue
> set_bit(SOCK_ASYNC_NOSPACE,&sock->flags);
> break;
> }
> + }
> if (unlikely(vhost_enable_notify(&net->dev, vq))) {
> vhost_disable_notify(&net->dev, vq);
> continue;
> }
> break;
No objection to add this but looks no difference to me as we won't touch
upend_idx and done_idx when zercocopy is not used.
>
> Second, whether it's possible the problem comes from tx_poll_start()? In
> some situation, vhost_poll_wakeup() is not being called?
>
> Thanks
> Shirley
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Network driver git tree
From: David Miller @ 2012-05-21 4:40 UTC (permalink / raw)
To: wkevils; +Cc: netdev
In-Reply-To: <CAGXs5wX3VAWNsV49Eg_Nznhbsuo4t=4b5h6_KrgPzPZ0=Qp4og@mail.gmail.com>
From: Kevin Wilson <wkevils@gmail.com>
Date: Mon, 21 May 2012 07:34:52 +0300
> In the past there was a git tree of Jeff Garzik for the network
> drivers; once in a while the net-next git tree pulled code from this
> tree. My short question is: currently, is a new, fresh network
> driver sent directly to net-next ? or is there some git tree similar
> to Jeff Garzik git tree (or maybe it does still exist)?
Jeff's tree hasn't existed in years.
All networking changes are sent to the net-next tree directly.
^ permalink raw reply
* Network driver git tree
From: Kevin Wilson @ 2012-05-21 4:34 UTC (permalink / raw)
To: netdev
Hi,
In the past there was a git tree of Jeff Garzik for the network
drivers; once in a while
the net-next git tree pulled code from this tree. My short question
is: currently, is
a new, fresh network driver sent directly to net-next ? or is there
some git tree similar to
Jeff Garzik git tree (or maybe it does still exist)?
regards,
Kevin
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-21 3:56 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Tom Herbert, netdev, e1000-devel, jeffrey.t.kirsher,
jesse.brandeburg, davem
In-Reply-To: <ef780bd0e0b9b9e60e37fa74101f0f66@visp.net.lb>
On Sun, 2012-05-20 at 22:18 +0300, Denys Fedoryshchenko wrote:
> On 2012-05-20 22:07, Eric Dumazet wrote:
> >
> > You could try latencytop, I am not sure if some obvious things will
> > popup.
> For sure i did. Nothing unusual here, max 5ms latency
> Cause Maximum
> Percentage
> [__skb_recv_datagram] 4.1 msec
Interesting
So your workload is a mix of pings, and receive.
Problem is softirq handler might use a lot of time to complete the
receives, because of TCP stack complexity. And BQL use softirq to
restart the transmits on the same cpu.
tcp_data_queue() can copy the received data directly to user space.
(taking page faults...)
Could you check if net-next behaves the same ?
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the tree
From: Stephen Rothwell @ 2012-05-21 2:27 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Parav Pandit, Roland Dreier, linux-rdma,
Somnath Kotur, Somnath Kotur
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit c72adfd767af
("be2net: Add functionality to support RoCE driver") from the infiniband
tree and commit 941a77d582c8 ("be2net: Fix to allow get/set of debug
levels in the firmware") from the net-next tree.
Just context changes. I fixed it up (see below) and carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/emulex/benet/be.h
index 7bb2e97,ff4eb8f..0000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -32,9 -32,8 +32,9 @@@
#include <linux/u64_stats_sync.h>
#include "be_hw.h"
+#include "be_roce.h"
- #define DRV_VER "4.2.116u"
+ #define DRV_VER "4.2.220u"
#define DRV_NAME "be2net"
#define BE_NAME "ServerEngines BladeEngine2 10Gbps NIC"
#define BE3_NAME "ServerEngines BladeEngine3 10Gbps NIC"
@@@ -379,22 -404,7 +406,18 @@@ struct be_adapter
u32 rx_fc; /* Rx flow control */
u32 tx_fc; /* Tx flow control */
bool stats_cmd_sent;
- int link_speed;
- u8 port_type;
- u8 transceiver;
- u8 autoneg;
u8 generation; /* BladeEngine ASIC generation */
+ u32 if_type;
+ struct {
+ u8 __iomem *base; /* Door Bell */
+ u32 size;
+ u32 total_size;
+ u64 io_addr;
+ } roce_db;
+ u32 num_msix_roce_vec;
+ struct ocrdma_dev *ocrdma_dev;
+ struct list_head entry;
+
u32 flash_status;
struct completion flash_compl;
@@@ -606,17 -603,7 +626,19 @@@ extern void be_link_status_update(struc
extern void be_parse_stats(struct be_adapter *adapter);
extern int be_load_fw(struct be_adapter *adapter, u8 *func);
extern bool be_is_wol_supported(struct be_adapter *adapter);
+ extern bool be_pause_supported(struct be_adapter *adapter);
+ extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+/*
+ * internal function to initialize-cleanup roce device.
+ */
+extern void be_roce_dev_add(struct be_adapter *);
+extern void be_roce_dev_remove(struct be_adapter *);
+
+/*
+ * internal function to open-close roce device during ifup-ifdown.
+ */
+extern void be_roce_dev_open(struct be_adapter *);
+extern void be_roce_dev_close(struct be_adapter *);
+
#endif /* BE_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Bluetooth: Fix null pointer dereference in l2cap_chan_send
From: Minho Ban @ 2012-05-21 0:58 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel
If l2cap_chan_send is called will null conn it will cause kernel Oops.
This patch checks if conn is valid before entering l2cap_chan_send.
2871 [ 177.271861] Unable to handle kernel NULL pointer dereference at virtual address 00000010
2872 [ 177.271867] pgd = eadc0000
2873 [ 177.271870] [00000010] *pgd=6ad03831, *pte=00000000, *ppte=00000000
2874 [ 177.271884] Internal error: Oops: 17 [#1] PREEMPT SMP
2875 [ 177.271891] Modules linked in:
2876 [ 177.271900] CPU: 3 Not tainted (3.0.15-00019-g097836e #36)
2877 [ 177.271925] PC is at l2cap_chan_send+0x8c/0x6f8
2878 [ 177.271933] LR is at 0xc089d59c
2879 [ 177.271940] pc : [<c0531514>] lr : [<c089d59c>] psr: 80000013
2880 [ 177.271943] sp : ddda1d50 ip : 0000035c fp : ddda1dac
2881 [ 177.271948] r10: 0000035c r9 : 00000000 r8 : ddda1f3c
2882 [ 177.271954] r7 : ed67ec00 r6 : 00000006 r5 : ed67ec00 r4 : 00000003
2883 [ 177.271959] r3 : ddda1d7c r2 : 0000035c r1 : 00000000 r0 : ed67ec00
2884 [ 177.271967] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
2885 [ 177.271973] Control: 10c5387d Table: 6adc004a DAC: 00000015
~~~ snip ~~~~~
3000 [ 177.272989] Backtrace:
3001 [ 177.273001] [<c0531488>] (l2cap_chan_send+0x0/0x6f8) from [<c053700c>] (l2cap_sock_sendmsg+0xc0/0x15c)
3002 [ 177.273023] [<c0536f4c>] (l2cap_sock_sendmsg+0x0/0x15c) from [<c0458afc>] (sock_sendmsg+0xcc/0xd4)
3003 [ 177.273035] [<c0458a30>] (sock_sendmsg+0x0/0xd4) from [<c0459558>] (sys_sendto+0xb8/0xdc)
3004 [ 177.273041] r9:ddda0000 r8:00004040 r7:00000000 r6:ebdf9d40 r5:0004fb00
3005 [ 177.273050] r4:0000035c
3006 [ 177.273059] [<c04594a0>] (sys_sendto+0x0/0xdc) from [<c045959c>] (sys_send+0x20/0x28)
3007 [ 177.273077] [<c045957c>] (sys_send+0x0/0x28) from [<c00431c0>] (ret_fast_syscall+0x0/0x30)
3008 [ 177.273087] Code: e5901004 e24b3030 e51ba050 e590e21c (e5914010)
3009 [ 177.273096] ---[ end trace 29a418305c9cffba ]---
Signed-off-by: Minho Ban <mhban@samsung.com>
---
net/bluetooth/l2cap_sock.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 3bb1611..98d4541 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -727,10 +727,12 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
- if (sk->sk_state != BT_CONNECTED)
+ l2cap_chan_lock(chan);
+ if (sk->sk_state != BT_CONNECTED || !chan->conn) {
+ l2cap_chan_unlock(chan);
return -ENOTCONN;
+ }
- l2cap_chan_lock(chan);
err = l2cap_chan_send(chan, msg, len, sk->sk_priority);
l2cap_chan_unlock(chan);
--
1.7.5.4
^ permalink raw reply related
* [RFC/PATCH] Bluetooth: prevent double l2cap_chan_destroy
From: Minho Ban @ 2012-05-21 0:56 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel
l2cap_sock_kill can be called in l2cap_sock_release and l2cap_sock_close_cb
either. This lead l2cap_chan_destroy to be called twice for same channel.
To prevent double list_del and double chan_put, chan_destroy should be protected
with chan->refcnt and chan_list_lock so that reentrance could be forbidden.
Signed-off-by: Minho Ban <mhban@samsung.com>
---
net/bluetooth/l2cap_core.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 24f144b..156ca14 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -400,10 +400,14 @@ struct l2cap_chan *l2cap_chan_create(void)
void l2cap_chan_destroy(struct l2cap_chan *chan)
{
write_lock(&chan_list_lock);
+ /* Check if channel is valid */
+ if (!atomic_read(&chan->refcnt)) {
+ write_unlock(&chan_list_lock);
+ return;
+ }
list_del(&chan->global_l);
- write_unlock(&chan_list_lock);
-
l2cap_chan_put(chan);
+ write_unlock(&chan_list_lock);
}
void l2cap_chan_set_defaults(struct l2cap_chan *chan)
--
1.7.5.4
^ permalink raw reply related
* [PATCH] drivers/net/stmmac: seq_file fix memory leak
From: Djalal Harouni @ 2012-05-20 23:55 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, David Miller
Use single_release() instead of seq_release() to free memory allocated
by single_open().
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 48d56da..a27e46c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1584,7 +1584,7 @@ static const struct file_operations stmmac_rings_status_fops = {
.open = stmmac_sysfs_ring_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static int stmmac_sysfs_dma_cap_read(struct seq_file *seq, void *v)
@@ -1656,7 +1656,7 @@ static const struct file_operations stmmac_dma_cap_fops = {
.open = stmmac_sysfs_dma_cap_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static int stmmac_init_fs(struct net_device *dev)
--
1.7.1
^ permalink raw reply related
* Re:
From: Mr. Peter Wong @ 2012-05-20 22:27 UTC (permalink / raw)
Good-Day Friend,
I Mr. Peter Wong, I Need Your Assistance
^ permalink raw reply
* Re: [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: ajb; +Cc: bjorn, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-2-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 20 May 2012 09:28:37 +0100
> Add the ZTE (Vodafone) K3765-Z to the whitelist. This requires the
> previous patch to make the whitelist with forced interface 4 generic
> or the device fails to initialise. After applying this patch and
> loading the Option driver without usb-modeswitch's bind all
> interfaces trick, a wwan0 net interface and /dev/cdc-wdm0 device
> file were created. Using Bjorn Mork's perl connection script a
> connection was made to a mobile network using QMI and the network
> interface's IPv4 address was configured OK.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] ipv6/exthdrs: strict Pad1 and PadN check
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1337515173-23648-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sun, 20 May 2012 13:59:33 +0200
> The following tightens the padding check from commit
> c1412fce7eccae62b4de22494f6ab3ff8a90c0c6 :
>
> * Take into account combinations of consecutive Pad1 and PadN.
>
> * Catch the corner case of when only padding is present in the
> header, when the extention header length is 0 (i.e., 8 bytes).
> In this case, the header would have exactly 6 bytes of padding:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> : Next Header : Hdr Ext Len=0 : :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
> : Padding (Pad1 or PadN) :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied to net-next, thanks a lot.
^ 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