* Re: [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Eric Dumazet @ 2012-07-27 17:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vijay Subramanian, netdev
In-Reply-To: <20120727100806.360764f5@nehalam.linuxnetplumber.net>
On Fri, 2012-07-27 at 10:08 -0700, Stephen Hemminger wrote:
> I am holding this until after 3.5 iproute2 is released.
>
> Still want to get a couple more features in 3.5 iproute2, the work Pavel is
> doing on save/restore cleanup, and the bridge fdb stuff.
>
By the way, it seems "ss -u" still uses /proc/net/udp , and not
inet_diag ?
^ permalink raw reply
* Re: bonding and SR-IOV -- do we need arp_validation for loadbalancing too?
From: Andy Gospodarek @ 2012-07-27 17:13 UTC (permalink / raw)
To: Chris Friesen; +Cc: Andy Gospodarek, Jay Vosburgh, Jiri Pirko, netdev, andy
In-Reply-To: <5012BEB1.9030306@genband.com>
On Fri, Jul 27, 2012 at 10:15:45AM -0600, Chris Friesen wrote:
> On 07/27/2012 08:55 AM, Andy Gospodarek wrote:
> >On Tue, Jul 24, 2012 at 03:38:11PM -0600, Chris Friesen wrote:
>
> >>In our environment (ATCA shelf) the switches have been customized to
> >>handle some of this stuff so arpmon does work reliably with xor.
> >Good.
> >
> >>In the general case it sounds like the "PF bonding ignores packets
> >>from VFs" is a better bet then.
> >It really might be. There are some registers in the 82599 datasheets
> >that are not used by the ixgbe driver, but might help you in this area.
> >
> >If you take a look at PFVML2FLT and PFUTA and their current status on
> >your system you might be able to put something together that gives you
> >what you want.
>
> I think it's simpler than that. By my reading of the 82599
> datasheet, the LB bit in the status field of the rx descriptor will
> indicate if the packet came from a VM.
>
Ah, you are correct. I'm curious if this bit is also set on VF<->VF
traffic.
> >It would likely mean you have to run a custom ixgbe-driver, but that
> >doesn't sound like much of an issue.
>
>
> While I'd like to avoid it if possible, we've already had to tweak
> the driver for other things.
As long as driver resets are not needed for some of these changes to
take effect, there is a chance you can write some of these bits from a
userspace program. I haven't done it myself, but I should try it. That
might allow you to run a stock driver from a distro and still get what
you want.
> The complication is that we've got a few different types of hardware
> and they're not all running 82599. I'm trying to figure out if the
> other hardware can do something similar.
That would indicate that this would be something that the stack as well
as some of the stacked modules bonding, vlans, bridges, etc. may need to
have some special code to handle. I'm not sure I'm a big fan right now,
but I'll hold off judgement until we see how this shakes out.
^ permalink raw reply
* Re: [PATCH v2 0/7] TCP Fast Open client
From: Jerry Chu @ 2012-07-27 17:28 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Yuchung Cheng, davem, edumazet, ncardwell, sivasankar, netdev,
rick jones, Terry Lam
In-Reply-To: <CAHO5Pa0D-hS=zdEEyUWMN6bmpKvQgiy25nTu1=BUYVxec+zpsQ@mail.gmail.com>
+rick, terry
Hi Michael,
Thanks for your interest!
On Fri, Jul 27, 2012 at 4:42 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
> Yuchung,
>
> On Wed, Jul 18, 2012 at 11:01 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> ChangeLog since v1:
>> - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>> - Clarify the purpose of using an experimental option in patch 1/7
>>
>> This patch series implement the client functionality of TCP Fast Open.
>> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
>> packets and consumed by the receiving end during the initial connection
>> handshake, thus providing a saving of up to one full round trip time (RTT)
>> compared to standard TCP requiring a three-way handshake (3WHS) to
>> complete before data can be exchanged.
>>
>> The protocol change is detailed in the IETF internet draft at
>> http://www.ietf.org/id/draft-ietf-tcpm-fastopen-00.txt . The research
>
> This URL appears to be invalid. I assume the following is the correct
> current version:
> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01
> ?
Correct.
>
> Is there some sample client and server userspace test code available?
There are some sample code in a SIGCOMM paper (
http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf). It's
real simple but we haven't published the server side code yet. (It's been
ready but I need to rebase it to the latest net-next.)
We will also be working with Rick Jones to add the Fast Open support to
netperf.
Best,
Jerry
>
> Thanks,
>
> Michael
>
> --
> Michael Kerrisk Linux man-pages maintainer;
> http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface", http://blog.man7.org/
^ permalink raw reply
* [PATCH] cxgb3: Set vlan_feature on net_device
From: brenohl @ 2012-07-27 18:22 UTC (permalink / raw)
To: jitendra.kalsaria, ron.mercer; +Cc: netdev, Breno Leitao
cxgb3 interface has a bad performance when VLAN is set. On my current
setup, a PowerLinux 7R2, I am able to get around 7 Gbps on a TCP_STREAM
(8 instances, 4k message).
With this patch, I am able to reach 9.5 Gbps.
Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index abb6ce7..fcf4b31 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3173,6 +3173,9 @@ static void __devinit cxgb3_init_iscsi_mac(struct net_device *dev)
pi->iscsic.mac_addr[3] |= 0x80;
}
+#define TSO_FLAGS (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_TSO_ECN)
+#define VLAN_FEAT (NETIF_F_SG | NETIF_F_IP_CSUM | TSO_FLAGS | \
+ NETIF_F_IPV6_CSUM | NETIF_F_HIGHDMA)
static int __devinit init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -3293,6 +3296,7 @@ static int __devinit init_one(struct pci_dev *pdev,
netdev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM |
NETIF_F_TSO | NETIF_F_RXCSUM | NETIF_F_HW_VLAN_RX;
netdev->features |= netdev->hw_features | NETIF_F_HW_VLAN_TX;
+ netdev->vlan_features |= netdev->features & VLAN_FEAT;
if (pci_using_dac)
netdev->features |= NETIF_F_HIGHDMA;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/7] netpoll: make __netpoll_cleanup non-block
From: Neil Horman @ 2012-07-27 18:40 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Jay Vosburgh, Andy Gospodarek,
Patrick McHardy, Stephen Hemminger, Jiri Pirko, Eric Dumazet,
Cong Wang, Joe Perches, linux-kernel, bridge
In-Reply-To: <1343403484-29347-3-git-send-email-amwang@redhat.com>
On Fri, Jul 27, 2012 at 11:37:59PM +0800, Cong Wang wrote:
> Like the previous patch, slave_disable_netpoll() and __netpoll_cleanup()
> may be called with read_lock() held too, so we should make them
> non-block, by moving the cleanup and kfree() to call_rcu_bh() callbacks.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> drivers/net/bonding/bond_main.c | 4 +--
> include/linux/netpoll.h | 3 ++
> net/8021q/vlan_dev.c | 6 +----
> net/bridge/br_device.c | 6 +----
> net/core/netpoll.c | 42 +++++++++++++++++++++++++++++---------
> 5 files changed, 38 insertions(+), 23 deletions(-)
><snip>
> struct netpoll_info *npinfo;
> @@ -903,20 +921,24 @@ void __netpoll_cleanup(struct netpoll *np)
> ops->ndo_netpoll_cleanup(np->dev);
>
> RCU_INIT_POINTER(np->dev->npinfo, NULL);
> + call_rcu_bh(&npinfo->rcu, rcu_cleanup_netpoll_info);
> + }
> +}
> +EXPORT_SYMBOL_GPL(__netpoll_cleanup);
>
> - /* avoid racing with NAPI reading npinfo */
> - synchronize_rcu_bh();
> +static void rcu_cleanup_netpoll(struct rcu_head *rcu_head)
> +{
> + struct netpoll *np = container_of(rcu_head, struct netpoll, rcu);
>
> - skb_queue_purge(&npinfo->arp_tx);
> - skb_queue_purge(&npinfo->txq);
> - cancel_delayed_work_sync(&npinfo->tx_work);
> + __netpoll_cleanup(np);
> + kfree(np);
> +}
>
> - /* clean after last, unfinished work */
> - __skb_queue_purge(&npinfo->txq);
> - kfree(npinfo);
> - }
> +void __netpoll_free_rcu(struct netpoll *np)
> +{
> + call_rcu_bh(&np->rcu, rcu_cleanup_netpoll);
Here, and above I see you using an rcu_head to defer cleanup, until after all
pointer uses are dropped, but I don't see any modification of code points that
dereference any struct netpoll pointers to include
rcu_read_lock()/rcu_read_unlock(). Without those using rcu to defer cleanup is
pointless, as the rcu code won't know when its safe to run. You're no better
off that you would be just calling __netpoll_cleanup directly.
Neil
> }
> -EXPORT_SYMBOL_GPL(__netpoll_cleanup);
> +EXPORT_SYMBOL_GPL(__netpoll_free_rcu);
>
> void netpoll_cleanup(struct netpoll *np)
> {
> --
> 1.7.7.6
>
>
^ permalink raw reply
* [PATCH] qlge: Add offload features to vlan interfaces
From: brenohl @ 2012-07-27 18:54 UTC (permalink / raw)
To: jitendra.kalsaria, ron.mercer; +Cc: netdev, Breno Leitao
This patch fills the net_device vlan_features with the proper hardware features,
thus, improving the vlan interface performance.
With the patch applied, I can see around 148% improvement on a TCP_STREAM test,
from 3.5 Gb/s to 8.7 Gb/s. On TCP_RR, I see a 11% improvement, from 18k
to 20. The CPU utilization is almost the same on both cases, from the comparison
above.
Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_main.c b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
index 3769f57..b53a3b6 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_main.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_main.c
@@ -4682,6 +4682,7 @@ static int __devinit qlge_probe(struct pci_dev *pdev,
NETIF_F_HW_VLAN_TX | NETIF_F_RXCSUM;
ndev->features = ndev->hw_features |
NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER;
+ ndev->vlan_features = ndev->hw_features;
if (test_bit(QL_DMA64, &qdev->flags))
ndev->features |= NETIF_F_HIGHDMA;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] cxgb3: Set vlan_feature on net_device
From: Breno Leitao @ 2012-07-27 18:57 UTC (permalink / raw)
To: brenohl; +Cc: jitendra.kalsaria, ron.mercer, netdev
In-Reply-To: <1343413351-48710-1-git-send-email-brenohl@br.ibm.com>
On 07/27/2012 03:22 PM, brenohl@br.ibm.com wrote:
> cxgb3 interface has a bad performance when VLAN is set. On my current
> setup, a PowerLinux 7R2, I am able to get around 7 Gbps on a TCP_STREAM
> (8 instances, 4k message).
> With this patch, I am able to reach 9.5 Gbps.
Please do not consider this patch. I'd send a qlge patch, but wrongly made
a shell-completion mistake and sent the wrong patch. The correct patch is
under its way.
^ permalink raw reply
* Re: [PATCH 00/16] Remove the ipv4 routing cache
From: Alexander Duyck @ 2012-07-27 19:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric W. Biederman, David Miller, netdev
In-Reply-To: <1343406533.2626.13104.camel@edumazet-glaptop>
On Fri, Jul 27, 2012 at 9:28 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Fri, 2012-07-27 at 09:23 -0700, Eric W. Biederman wrote:
>
>> I am familiar. But does hardware prefetching make a difference
>> if your object is less than 64 bytes?
>>
>
> Apparently yes, if the prefetch touches a dirtied neighbour cache line.
>
>> I don't believe only allocating 64 bytes will be a problem,
>> as no one else well be dirtying your cache line.
>>
>> I suppose you could run into pathologies where your object
>> is 3*64 bytes in size, but your expression doesn't handle
>> that case either.
>>
>
> Sure, but in most cases fib objects are under 128 bytes.
>
>
>> The other alternative to guarantee very good cache behavior is
>> to ensure you are allocating a power of two size up to some limit,
>> perhaps page size.
>>
>
> Good idea.
>
>> My point is the magic 128 likely requires an explicatory comment and I
>> think the net result is you have encoded something fragile that is good
>> for testing but that will in the fullness of time do strange things that
>> will be easy to overlook.
>
> Sure, I'll send a v2, thanks.
>
>
I tested out v1 of your patch and didn't seem much of a change in my
test environment. I figure I will spend most of today going through
the code trying to figure out what is causing the issues I am seeing
and why your changes had no effect on my setup.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 0/7] TCP Fast Open client
From: Michael Kerrisk @ 2012-07-27 19:06 UTC (permalink / raw)
To: Jerry Chu
Cc: Yuchung Cheng, davem, edumazet, ncardwell, sivasankar, netdev,
rick jones, Terry Lam, Michael Kerrisk
In-Reply-To: <CAPshTCjxUQ=juO3POX1oSaLTO_g3EmxjQNkSxLjEZGyxDBkMJQ@mail.gmail.com>
On Fri, Jul 27, 2012 at 7:28 PM, Jerry Chu <hkchu@google.com> wrote:
> +rick, terry
>
> Hi Michael,
>
> Thanks for your interest!
>
> On Fri, Jul 27, 2012 at 4:42 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>> Yuchung,
>>
>> On Wed, Jul 18, 2012 at 11:01 PM, Yuchung Cheng <ycheng@google.com> wrote:
>>> ChangeLog since v1:
>>> - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>>> - Clarify the purpose of using an experimental option in patch 1/7
>>>
>>> This patch series implement the client functionality of TCP Fast Open.
>>> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
>>> packets and consumed by the receiving end during the initial connection
>>> handshake, thus providing a saving of up to one full round trip time (RTT)
>>> compared to standard TCP requiring a three-way handshake (3WHS) to
>>> complete before data can be exchanged.
>>>
>>> The protocol change is detailed in the IETF internet draft at
>>> http://www.ietf.org/id/draft-ietf-tcpm-fastopen-00.txt . The research
>>
>> This URL appears to be invalid. I assume the following is the correct
>> current version:
>> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01
>> ?
>
> Correct.
>
>>
>> Is there some sample client and server userspace test code available?
>
> There are some sample code in a SIGCOMM paper (
> http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf). It's
> real simple but we haven't published the server side code yet. (It's been
> ready but I need to rebase it to the latest net-next.)
The examples in that paper seem to be outdated. At the very least,
names of constants for socket options etc have changed.
I've been trying to test this feature from userspace, but am not
getting quite the results I expect. It sounds like you are saying that
not all the kernel pieces are there yet to support TFO in userspace.
Is that correct?
Thanks,
Michael
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
^ permalink raw reply
* TCP stalls with 802.3ad + bridge + kvm guest
From: Peter Samuelson @ 2012-07-27 18:38 UTC (permalink / raw)
To: netdev; +Cc: jgoerzen
So, we have the following network stack:
ixgbe [10 Gbit port] -- bonding [802.3ad] -- bridge -- KVM guest
(There's also a VLAN layer, but I can reproduce this problem without
it.) It all works, except that with some flows in the KVM guest - I
can reproduce using smbclient - transfers keep stalling, such that I'm
averaging well under 1 MB/s. Should be more like 100 MB/s.
Oddly, this only occurs when both the 802.3ad and KVM are used:
Server Agg Client TCP stalls
--------------------------------------------------
external none KVM guest no
external 802.3ad KVM host no
KVM host 802.3ad KVM guest no
external 802.3ad KVM guest yes
I don't understand the stalls. 'ping -f' does not show any dropped
packets. tcpdump seems to show a lot of retransmits (server to
client), out-of-order TCP segments (server to client), and duplicate
ACKs (client to server).
Further notes:
- OS for KVM host (and guest) is Debian stable, with kernels from
Debian backports. I've tried several kernels including 3.4,
currently using 3.2.20.
- Arista 10 Gbit switch, no congestion to speak of, all the test
traffic is local to the switch.
- I can reproduce with either 1 or 2 active ports in the LACP group.
- The host IP is bound to the bridge, not directly to bond0.
- First noticed problem with a Windows VM and SMB. I can reproduce
100% using smbclient, but wget (http) goes full speed.
Does any of this sound familiar? Is it a known issue? Can anyone
offer any hints? I can run tcpdump on the client, the server or any
point in the KVM host network stack, in case anyone is better at
interpreting them than I am.
Thanks,
Peter
^ permalink raw reply
* Re: [PATCH v2 0/7] TCP Fast Open client
From: Jerry Chu @ 2012-07-27 19:39 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Yuchung Cheng, davem, edumazet, ncardwell, sivasankar, netdev,
rick jones, Terry Lam
In-Reply-To: <CAHO5Pa3eLRrjGx52o26sN9OS7PMbKu3e3=Zz72E7Z6i5XwDnvw@mail.gmail.com>
On Fri, Jul 27, 2012 at 12:06 PM, Michael Kerrisk
<mtk.manpages@gmail.com> wrote:
> On Fri, Jul 27, 2012 at 7:28 PM, Jerry Chu <hkchu@google.com> wrote:
>> +rick, terry
>>
>> Hi Michael,
>>
>> Thanks for your interest!
>>
>> On Fri, Jul 27, 2012 at 4:42 AM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>>> Yuchung,
>>>
>>> On Wed, Jul 18, 2012 at 11:01 PM, Yuchung Cheng <ycheng@google.com> wrote:
>>>> ChangeLog since v1:
>>>> - Reduce tons of code by storing Fast Open stats in the TCP metrics :)
>>>> - Clarify the purpose of using an experimental option in patch 1/7
>>>>
>>>> This patch series implement the client functionality of TCP Fast Open.
>>>> TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK
>>>> packets and consumed by the receiving end during the initial connection
>>>> handshake, thus providing a saving of up to one full round trip time (RTT)
>>>> compared to standard TCP requiring a three-way handshake (3WHS) to
>>>> complete before data can be exchanged.
>>>>
>>>> The protocol change is detailed in the IETF internet draft at
>>>> http://www.ietf.org/id/draft-ietf-tcpm-fastopen-00.txt . The research
>>>
>>> This URL appears to be invalid. I assume the following is the correct
>>> current version:
>>> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01
>>> ?
>>
>> Correct.
>>
>>>
>>> Is there some sample client and server userspace test code available?
>>
>> There are some sample code in a SIGCOMM paper (
>> http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf). It's
>> real simple but we haven't published the server side code yet. (It's been
>> ready but I need to rebase it to the latest net-next.)
>
> The examples in that paper seem to be outdated. At the very least,
> names of constants for socket options etc have changed.
>
> I've been trying to test this feature from userspace, but am not
> getting quite the results I expect. It sounds like you are saying that
> not all the kernel pieces are there yet to support TFO in userspace.
> Is that correct?
Correct. Only the client side code is in net-next but not the server
code. If you
tcpdump you'll see your TFO TCP option is not getting ack'ed because the
server side does not understand TFO yet.
The server side code is ready for review as well, except I just discovered
an implementation detail that I need to fix - I have conveniently added TCP
code for TFO directly to request_sock.c but just realized request_sock is
being used by non-TCP transport (e.g., DCCP) as well so I need to remove
TCP specific code and make it more generic wrt rsk...
Anyway hopefully the code will be ready for review soon (i'm leaving for
vacation in a few days so it will be a little more delay). If you can't wait to
test it i can send you a patch.
Thanks,
Jerry
>
> Thanks,
>
> Michael
>
> --
> Michael Kerrisk Linux man-pages maintainer;
> http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface", http://blog.man7.org/
^ permalink raw reply
* Re: [PATCH v2 0/7] TCP Fast Open client
From: Vijay Subramanian @ 2012-07-27 19:52 UTC (permalink / raw)
To: Jerry Chu
Cc: Michael Kerrisk, Yuchung Cheng, davem, edumazet, ncardwell,
sivasankar, netdev, rick jones, Terry Lam
In-Reply-To: <CAPshTCgR585z5sFUbxgR5azb2kZe2mnx=x6i_0M=iint5NEpJg@mail.gmail.com>
>
> Anyway hopefully the code will be ready for review soon (i'm leaving for
> vacation in a few days so it will be a little more delay). If you can't wait to
> test it i can send you a patch.
>
Jerry,
If you don't mind, can you CC me the patches too if they are ready? I
was planning to test TFO too and was waiting for the server side
patches,
For the user space, as far as I understand, replacing connect() with
sendmsg() with MSG_FASTOPEN flag should be the only change needed
right?
Thanks,
Vijay
^ permalink raw reply
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Jay Vosburgh @ 2012-07-27 20:00 UTC (permalink / raw)
To: Peter Samuelson; +Cc: netdev, jgoerzen
In-Reply-To: <20120727183840.GE17572@p12n.org>
Peter Samuelson <psamuelson@efolder.net> wrote:
>So, we have the following network stack:
>
> ixgbe [10 Gbit port] -- bonding [802.3ad] -- bridge -- KVM guest
>
>(There's also a VLAN layer, but I can reproduce this problem without
>it.) It all works, except that with some flows in the KVM guest - I
>can reproduce using smbclient - transfers keep stalling, such that I'm
>averaging well under 1 MB/s. Should be more like 100 MB/s.
>
>Oddly, this only occurs when both the 802.3ad and KVM are used:
>
> Server Agg Client TCP stalls
> --------------------------------------------------
> external none KVM guest no
> external 802.3ad KVM host no
> KVM host 802.3ad KVM guest no
> external 802.3ad KVM guest yes
Does the "none" for Agg (the first line) mean no bonding at all?
Does the problem happen if the bond is a different mode
(balance-xor, for example)?
>I don't understand the stalls. 'ping -f' does not show any dropped
>packets. tcpdump seems to show a lot of retransmits (server to
>client), out-of-order TCP segments (server to client), and duplicate
>ACKs (client to server).
Do the various stats on the host and guest show any drops?
E.g., from "netstat -i" and "tc -s qdisc"
>Further notes:
>
>- OS for KVM host (and guest) is Debian stable, with kernels from
> Debian backports. I've tried several kernels including 3.4,
> currently using 3.2.20.
>
>- Arista 10 Gbit switch, no congestion to speak of, all the test
> traffic is local to the switch.
>
>- I can reproduce with either 1 or 2 active ports in the LACP group.
>
>- The host IP is bound to the bridge, not directly to bond0.
>
>- First noticed problem with a Windows VM and SMB. I can reproduce
> 100% using smbclient, but wget (http) goes full speed.
>
>Does any of this sound familiar? Is it a known issue? Can anyone
>offer any hints? I can run tcpdump on the client, the server or any
>point in the KVM host network stack, in case anyone is better at
>interpreting them than I am.
Maybe; I've seen a similar-sounding problem with CIFS wherein
the loss of the last or near-last packet that's part of the CIFS request
will cause TCP to run a full RTO. This occurs because CIFS has no more
packets to send, as it's waiting for a response, so there is no
subsequent traffic that will trigger duplicate ACKs from the peer and
thus initiate a fast retransmission. I may be mangling the CIFS
details, but that's the packet exchange that occurs, and it resulted in
very poor performance for CIFS.
The case I saw this in was not using KVM, but was instead
dropping some packets at a network bottleneck. In that case, CIFS
experienced the poor performance, but NFS did not; the NFS packet
captures also showed the lost packets, but NFS would continue to send
and issue fast retransmissions in response to the duplicate ACKs it
received. Perhaps this mirrors your experience with CIFS vs. wget, and
your bottleneck is somewhere on the host itself in the virtual
networking.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* [PATCH] Revert "openvswitch: potential NULL deref in sample()"
From: Jesse Gross @ 2012-07-27 20:19 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
Dan Carpenter
This reverts commit 5b3e7e6cb5771bedda51cdb6f715d1da8cd9e644.
The problem that the original commit was attempting to fix can
never happen in practice because validation is done one a per-flow
basis rather than a per-packet basis. Adding additional checks at
runtime is unnecessary and inconsistent with the rest of the code.
CC: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/actions.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 320fa0e..f3f96ba 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -325,9 +325,6 @@ static int sample(struct datapath *dp, struct sk_buff *skb,
}
}
- if (!acts_list)
- return 0;
-
return do_execute_actions(dp, skb, nla_data(acts_list),
nla_len(acts_list), true);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] tcp: perform DMA to userspace only if there is a task waiting for it
From: David Miller @ 2012-07-27 20:31 UTC (permalink / raw)
To: jkosina; +Cc: christopher.leech, linux-kernel, netdev, jbohac
In-Reply-To: <alpine.LNX.2.00.1207271556320.11375@pobox.suse.cz>
From: Jiri Kosina <jkosina@suse.cz>
Date: Fri, 27 Jul 2012 16:05:06 +0200 (CEST)
> #ifdef CONFIG_NET_DMA
> - if (tcp_dma_try_early_copy(sk, skb, tcp_header_len)) {
> + if (tp->ucopy.task == current &&
> + sock_owned_by_user(sk) &&
> + tcp_dma_try_early_copy(sk,
> + skb, tcp_header_len)) {
This indentation is absolutely terrible.
If you are only able to indent lines using TAB characters, rather than
using an appropriate mixture of TAB and SPACE characters to get the
lines to line up properly, please do not even bother submitting
patches here.
^ permalink raw reply
* [PATCH v2] tcp: perform DMA to userspace only if there is a task waiting for it
From: Jiri Kosina @ 2012-07-27 20:38 UTC (permalink / raw)
To: David Miller; +Cc: christopher.leech, linux-kernel, netdev, jbohac
In-Reply-To: <20120727.133135.2017747630291360657.davem@davemloft.net>
Back in 2006, commit 1a2449a87b ("[I/OAT]: TCP recv offload to I/OAT")
added support for receive offloading to IOAT dma engine if available.
The code in tcp_rcv_established() tries to perform early DMA copy if
applicable. It however does so without checking whether the userspace
task is actually expecting the data in the buffer.
This is not a problem under normal circumstances, but there is a corner
case where this doesn't work -- and that's when MSG_TRUNC flag to
recvmsg() is used.
If the IOAT dma engine is not used, the code properly checks whether
there is a valid ucopy.task and the socket is owned by userspace, but
misses the check in the dmaengine case.
This problem can be observed in real trivially -- for example 'tbench' is a
good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing
IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they
have been already early-copied in tcp_rcv_established() using dma engine.
This patch introduces the same check we are performing in the simple
iovec copy case to the IOAT case as well. It fixes the indefinite
recvmsg(MSG_TRUNC) hangs.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
net/ipv4/tcp_input.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 3e07a64..76e3bf6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5475,7 +5475,9 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
if (tp->copied_seq == tp->rcv_nxt &&
len - tcp_header_len <= tp->ucopy.len) {
#ifdef CONFIG_NET_DMA
- if (tcp_dma_try_early_copy(sk, skb, tcp_header_len)) {
+ if (tp->ucopy.task == current &&
+ sock_owned_by_user(sk) &&
+ tcp_dma_try_early_copy(sk, skb, tcp_header_len)) {
copied_early = 1;
eaten = 1;
}
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH net-next] GRE over IPv6
From: David Miller @ 2012-07-27 20:42 UTC (permalink / raw)
To: xeb; +Cc: netdev
In-Reply-To: <1588984.2XtHtDpxor@dima>
Why have you submitted these patches two times?
^ permalink raw reply
* Re: [PATCH] tcp: Add TCP_USER_TIMEOUT negative value check
From: David Miller @ 2012-07-27 20:46 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, hkchu
In-Reply-To: <1343379141-5516-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Fri, 27 Jul 2012 16:52:21 +0800
> TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
> patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c75) didn't check the negative
> values. If a user assign -1 to it, the socket will set successfully and wait
> for 4294967295 miliseconds. This patch add a negative value check to avoid
> this issue.
>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] USB: kaweth.c: use GFP_ATOMIC under spin_lock
From: David Miller @ 2012-07-27 20:46 UTC (permalink / raw)
To: dan.carpenter; +Cc: gregkh, linux-usb, netdev, kernel-janitors
In-Reply-To: <20120727114651.GA15492@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri, 27 Jul 2012 14:46:51 +0300
> The problem is that we call this with a spin lock held. The call tree
> is:
> kaweth_start_xmit() holds kaweth->device_lock.
> -> kaweth_async_set_rx_mode()
> -> kaweth_control()
> -> kaweth_internal_control_msg()
>
> The kaweth_internal_control_msg() function is only called from
> kaweth_control() which used GFP_ATOMIC for its allocations.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling
From: David Miller @ 2012-07-27 20:46 UTC (permalink / raw)
To: jbenc; +Cc: netdev, makc
In-Reply-To: <20120727145822.7efd10d4@griffin>
From: Jiri Benc <jbenc@redhat.com>
Date: Fri, 27 Jul 2012 14:58:22 +0200
> When device flags are set using rtnetlink, IFF_PROMISC and IFF_ALLMULTI
> flags are handled specially. Function dev_change_flags sets IFF_PROMISC and
> IFF_ALLMULTI bits in dev->gflags according to the passed value but
> do_setlink passes a result of rtnl_dev_combine_flags which takes those bits
> from dev->flags.
>
> This can be easily trigerred by doing:
>
> tcpdump -i eth0 &
> ip l s up eth0
>
> ip sets IFF_UP flag in ifi_flags and ifi_change, which is combined with
> IFF_PROMISC by rtnl_dev_combine_flags, causing __dev_change_flags to set
> IFF_PROMISC in gflags.
>
> Reported-by: Max Matveev <makc@redhat.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv4: fix TCP early demux
From: David Miller @ 2012-07-27 20:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1343406220.2626.13092.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Jul 2012 18:23:40 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> commit 92101b3b2e317 (ipv4: Prepare for change of rt->rt_iif encoding.)
> invalidated TCP early demux, because rx_dst_ifindex is not properly
> initialized and checked.
>
> Also remove the use of inet_iif(skb) in favor or skb->skb_iif
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Revert "openvswitch: potential NULL deref in sample()"
From: David Miller @ 2012-07-27 20:47 UTC (permalink / raw)
To: jesse; +Cc: netdev, dev, dan.carpenter
In-Reply-To: <1343420380-23119-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 27 Jul 2012 13:19:40 -0700
> This reverts commit 5b3e7e6cb5771bedda51cdb6f715d1da8cd9e644.
>
> The problem that the original commit was attempting to fix can
> never happen in practice because validation is done one a per-flow
> basis rather than a per-packet basis. Adding additional checks at
> runtime is unnecessary and inconsistent with the rest of the code.
>
> CC: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] tcp: perform DMA to userspace only if there is a task waiting for it
From: David Miller @ 2012-07-27 20:48 UTC (permalink / raw)
To: jkosina; +Cc: christopher.leech, linux-kernel, netdev, jbohac
In-Reply-To: <alpine.LNX.2.00.1207272237470.30412@pobox.suse.cz>
From: Jiri Kosina <jkosina@suse.cz>
Date: Fri, 27 Jul 2012 22:38:50 +0200 (CEST)
> Back in 2006, commit 1a2449a87b ("[I/OAT]: TCP recv offload to I/OAT")
> added support for receive offloading to IOAT dma engine if available.
>
> The code in tcp_rcv_established() tries to perform early DMA copy if
> applicable. It however does so without checking whether the userspace
> task is actually expecting the data in the buffer.
>
> This is not a problem under normal circumstances, but there is a corner
> case where this doesn't work -- and that's when MSG_TRUNC flag to
> recvmsg() is used.
>
> If the IOAT dma engine is not used, the code properly checks whether
> there is a valid ucopy.task and the socket is owned by userspace, but
> misses the check in the dmaengine case.
>
> This problem can be observed in real trivially -- for example 'tbench' is a
> good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing
> IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they
> have been already early-copied in tcp_rcv_established() using dma engine.
>
> This patch introduces the same check we are performing in the simple
> iovec copy case to the IOAT case as well. It fixes the indefinite
> recvmsg(MSG_TRUNC) hangs.
>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Vlad Yasevich @ 2012-07-27 21:22 UTC (permalink / raw)
To: Xufeng Zhang
Cc: Neil Horman, xufeng zhang, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <CA+=dFzguqjjnnqHO53Mx859VB6NU=4MaPWAUzGQB2qtZGfdAUg@mail.gmail.com>
here is an untested prototype of what I was talking about. This should
handle multiple data chunks.
-vlad
---
include/net/sctp/command.h | 1 +
net/sctp/sm_sideeffect.c | 22 ++++++++++++++++++++++
net/sctp/sm_statefuns.c | 18 ++++++++++--------
3 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
index 712b3be..4043445 100644
--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -110,6 +110,7 @@ typedef enum {
SCTP_CMD_SEND_NEXT_ASCONF, /* Send the next ASCONF after ACK */
SCTP_CMD_PURGE_ASCONF_QUEUE, /* Purge all asconf queues.*/
SCTP_CMD_SET_ASOC, /* Restore association context */
+ SCTP_CMD_GEN_BAD_STREAM, /* Issue an Invalid Stream error */
SCTP_CMD_LAST
} sctp_verb_t;
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 1ff51c9..c5a1322 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1036,6 +1036,22 @@ static void sctp_cmd_send_asconf(struct
sctp_association *asoc)
}
}
+static void sctp_cmd_make_inv_stream_err(sctp_cmd_seq_t *commands,
+ struct sctp_association *asoc,
+ struct sctp_chunk *chunk,
+ struct sctp_datahdr *data_hdr)
+{
+ struct sctp_chunk *err;
+
+ err = sctp_make_op_error(asoc, chunk, SCTP_ERROR_INV_STRM,
+ &data_hdr->stream,
+ sizeof(data_hdr->stream),
+ sizeof(u16));
+ if (err)
+ sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
+ SCTP_CHUNK(err));
+}
+
/* These three macros allow us to pull the debugging code out of the
* main flow of sctp_do_sm() to keep attention focused on the real
@@ -1700,6 +1716,12 @@ static int sctp_cmd_interpreter(sctp_event_t
event_type,
asoc = cmd->obj.asoc;
break;
+ case SCTP_CMD_GEN_BAD_STREAM:
+ sctp_cmd_make_inv_stream_err(commands,
+ asoc, chunk,
+ (struct sctp_datahdr *)cmd->obj.ptr);
+ break;
+
default:
pr_warn("Impossible command: %u, %p\n",
cmd->verb, cmd->obj.ptr);
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 891f5db..57532e3 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -2972,6 +2972,12 @@ discard_noforce:
if (chunk->end_of_packet)
sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, force);
+ /* Queue the INVALID STREAM error after the SACK if one is needed. */
+ if (SCTP_IERROR_BAD_STREAM == error) {
+ sctp_add_cmd_sf(commands, SCTP_CMD_GEN_BAD_STREAM,
+ SCTP_PTR(chunk->subh.data_hdr));
+ }
+
return SCTP_DISPOSITION_DISCARD;
consume:
return SCTP_DISPOSITION_CONSUME;
@@ -3044,6 +3050,10 @@ sctp_disposition_t
sctp_sf_eat_data_fast_4_4(const struct sctp_endpoint *ep,
*/
sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SHUTDOWN, SCTP_NULL());
sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE());
+ if (SCTP_IERROR_BAD_STREAM == error) {
+ sctp_add_cmd_sf(commands, SCTP_CMD_GEN_BAD_STREAM,
+ SCTP_PTR(chunk->subh.data_hdr));
+ }
sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
SCTP_TO(SCTP_EVENT_TIMEOUT_T2_SHUTDOWN));
}
@@ -6140,14 +6150,6 @@ static int sctp_eat_data(const struct
sctp_association *asoc,
if (sid >= asoc->c.sinit_max_instreams) {
/* Mark tsn as received even though we drop it */
sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_TSN, SCTP_U32(tsn));
-
- err = sctp_make_op_error(asoc, chunk, SCTP_ERROR_INV_STRM,
- &data_hdr->stream,
- sizeof(data_hdr->stream),
- sizeof(u16));
- if (err)
- sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
- SCTP_CHUNK(err));
return SCTP_IERROR_BAD_STREAM;
}
-- 1.7.7.6
^ permalink raw reply related
* Re: pull request: wireless 2012-07-27
From: David Miller @ 2012-07-27 21:26 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20120727155806.GB6110@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 27 Jul 2012 11:58:06 -0400
> These fixes are intended for the 3.6 stream.
>
> Hauke Mehrtens provides a pair of bcma fixes, one to fix a build
> regression on mips and another to correct a pair of missing iounmap
> calls.
>
> Thomas Huehn offers a mac80211_hwsim fix to avoid a possible
> use-after-free bug.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ 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