* 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 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
* [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] 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] 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: 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
* 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: [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
* 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: 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
* 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] 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
* [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 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] 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 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
* 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 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: [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Stephen Hemminger @ 2012-07-27 17:08 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, netdev
In-Reply-To: <CAGK4HS-fUp2ZiW9F_ZogOXQo5_2ptcBHT9Y2j25ZaoXrYKnbAQ@mail.gmail.com>
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.
^ permalink raw reply
* Re: [PATCH 2/2] iproute: Add route showdump command (v2)
From: Stephen Hemminger @ 2012-07-27 17:05 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <50122FD7.2060701@parallels.com>
On Fri, 27 Jul 2012 10:06:15 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> I mean something like the below, just put the RTM_GETADDR stream into a
> file and push it back into the kernel as is. It worked for me in trivial
> cases, but is this approach correct generically?
It is supposed to always work to reverse netlink messages back to the kernel.
There a couple of caveats:
1. Some fields like statistics are just ignored by the kernel and can never
be reset.
2. The feature isn't commonly used and it is always possible that it will
expose a kernel bug.
^ permalink raw reply
* Re: [PATCH 1/2] iproute: Add magic cookie to route dump file
From: Stephen Hemminger @ 2012-07-27 16:59 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <50121F4D.8090606@parallels.com>
On Fri, 27 Jul 2012 08:55:41 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> In order to somehow verify that a blob contains route dump a
> 4-bytes magic is put at the head of the data and is checked
> on restore.
>
> Magic digits are taken from Portland (OR) coordinates :) Is
> there any more reliable way of generating such?
>
> Signed-of-by: Pavel Emelyanov <xemul@parallels.com>
>
Any magic number is fine as long as it is non-offensive and
unique.
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/3] CAN Filter/Classifier
From: Oliver Hartkopp @ 2012-07-27 16:35 UTC (permalink / raw)
To: Rostislav Lisovy
Cc: Marc Kleine-Budde, netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1343398165.12164.3.camel@lolumad>
On 27.07.2012 16:09, Rostislav Lisovy wrote:
> On Fri, 2012-07-27 at 15:56 +0200, Oliver Hartkopp wrote:
>> On 27.07.2012 12:02, Marc Kleine-Budde wrote:
>>
>>> I'm reposting Rostislav's iproute2 patches, as Stephen requested,
>>> during the v3.6 merge window with the corresponding kernel patches
>>> already applied.
>>
>>
>
>> Btw. i think these patches address the original implementation from Rostislav
>> using the CAN classifier. The review lead to a completely new implementation
>> using ematch. Therefore this patch series is outdated AFAICS.
>>
>> @Rostislav: Am i correct here?
>
> Hello Oliver;
> You are right -- these are the patches for the old "standalone can
> filter/classifier" implementation.
> I will send correct patches hopefully on Monday/Tuesday.
>
No hurry.
I will not have the time next week to check out and test your patches.
But i would like to do so :-)
We have all the time until Linux 3.6 is released somewhere in October.
So getting these things done in August is a good target.
Tnx & best regards,
Oliver
^ permalink raw reply
* [patch net-next 4/4] team: add support for queue override by setting queue_id for port
From: Jiri Pirko @ 2012-07-27 16:28 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet
In-Reply-To: <1343406535-22388-1-git-send-email-jiri@resnulli.us>
Similar to what bonding has. This allows to set queue_id for port so
this port will be used when skb with matching skb->queue_mapping is
going to be transmitted.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/team/team.c | 163 ++++++++++++++++++++++++++++++++++++++++++++++-
include/linux/if_team.h | 4 ++
2 files changed, 165 insertions(+), 2 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index a30b7c1..ba10c46 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -658,6 +658,122 @@ static rx_handler_result_t team_handle_frame(struct sk_buff **pskb)
}
+/*************************************
+ * Multiqueue Tx port select override
+ *************************************/
+
+static int team_queue_override_init(struct team *team)
+{
+ struct list_head *listarr;
+ unsigned int queue_cnt = team->dev->num_tx_queues - 1;
+ unsigned int i;
+
+ if (!queue_cnt)
+ return 0;
+ listarr = kmalloc(sizeof(struct list_head) * queue_cnt, GFP_KERNEL);
+ if (!listarr)
+ return -ENOMEM;
+ team->qom_lists = listarr;
+ for (i = 0; i < queue_cnt; i++)
+ INIT_LIST_HEAD(listarr++);
+ return 0;
+}
+
+static void team_queue_override_fini(struct team *team)
+{
+ kfree(team->qom_lists);
+}
+
+static struct list_head *__team_get_qom_list(struct team *team, u16 queue_id)
+{
+ return &team->qom_lists[queue_id - 1];
+}
+
+/*
+ * note: already called with rcu_read_lock
+ */
+static bool team_queue_override_transmit(struct team *team, struct sk_buff *skb)
+{
+ struct list_head *qom_list;
+ struct team_port *port;
+
+ if (!team->queue_override_enabled || !skb->queue_mapping)
+ return false;
+ qom_list = __team_get_qom_list(team, skb->queue_mapping);
+ list_for_each_entry_rcu(port, qom_list, qom_list) {
+ if (!team_dev_queue_xmit(team, port, skb))
+ return true;
+ }
+ return false;
+}
+
+static void __team_queue_override_port_del(struct team *team,
+ struct team_port *port)
+{
+ list_del_rcu(&port->qom_list);
+ synchronize_rcu();
+ INIT_LIST_HEAD(&port->qom_list);
+}
+
+static bool team_queue_override_port_has_gt_prio_than(struct team_port *port,
+ struct team_port *cur)
+{
+ if (port->priority < cur->priority)
+ return true;
+ if (port->priority > cur->priority)
+ return false;
+ if (port->index < cur->index)
+ return true;
+ return false;
+}
+
+static void __team_queue_override_port_add(struct team *team,
+ struct team_port *port)
+{
+ struct team_port *cur;
+ struct list_head *qom_list;
+ struct list_head *node;
+
+ if (!port->queue_id || !team_port_enabled(port))
+ return;
+
+ qom_list = __team_get_qom_list(team, port->queue_id);
+ node = qom_list;
+ list_for_each_entry(cur, qom_list, qom_list) {
+ if (team_queue_override_port_has_gt_prio_than(port, cur))
+ break;
+ node = &cur->qom_list;
+ }
+ list_add_tail_rcu(&port->qom_list, node);
+}
+
+static void __team_queue_override_enabled_check(struct team *team)
+{
+ struct team_port *port;
+ bool enabled = false;
+
+ list_for_each_entry(port, &team->port_list, list) {
+ if (!list_empty(&port->qom_list)) {
+ enabled = true;
+ break;
+ }
+ }
+ if (enabled == team->queue_override_enabled)
+ return;
+ netdev_dbg(team->dev, "%s queue override\n",
+ enabled ? "Enabling" : "Disabling");
+ team->queue_override_enabled = enabled;
+}
+
+static void team_queue_override_port_refresh(struct team *team,
+ struct team_port *port)
+{
+ __team_queue_override_port_del(team, port);
+ __team_queue_override_port_add(team, port);
+ __team_queue_override_enabled_check(team);
+}
+
+
/****************
* Port handling
****************/
@@ -688,6 +804,7 @@ static void team_port_enable(struct team *team,
hlist_add_head_rcu(&port->hlist,
team_port_index_hash(team, port->index));
team_adjust_ops(team);
+ team_queue_override_port_refresh(team, port);
if (team->ops.port_enabled)
team->ops.port_enabled(team, port);
}
@@ -716,6 +833,7 @@ static void team_port_disable(struct team *team,
hlist_del_rcu(&port->hlist);
__reconstruct_port_hlist(team, port->index);
port->index = -1;
+ team_queue_override_port_refresh(team, port);
__team_adjust_ops(team, team->en_port_count - 1);
/*
* Wait until readers see adjusted ops. This ensures that
@@ -881,6 +999,7 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
port->dev = port_dev;
port->team = team;
+ INIT_LIST_HEAD(&port->qom_list);
port->orig.mtu = port_dev->mtu;
err = dev_set_mtu(port_dev, dev->mtu);
@@ -1107,9 +1226,34 @@ static int team_priority_option_set(struct team *team,
struct team_port *port = ctx->info->port;
port->priority = ctx->data.s32_val;
+ team_queue_override_port_refresh(team, port);
return 0;
}
+static int team_queue_id_option_get(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->info->port;
+
+ ctx->data.u32_val = port->queue_id;
+ return 0;
+}
+
+static int team_queue_id_option_set(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->info->port;
+
+ if (port->queue_id == ctx->data.u32_val)
+ return 0;
+ if (ctx->data.u32_val >= team->dev->real_num_tx_queues)
+ return -EINVAL;
+ port->queue_id = ctx->data.u32_val;
+ team_queue_override_port_refresh(team, port);
+ return 0;
+}
+
+
static const struct team_option team_options[] = {
{
.name = "mode",
@@ -1145,6 +1289,13 @@ static const struct team_option team_options[] = {
.getter = team_priority_option_get,
.setter = team_priority_option_set,
},
+ {
+ .name = "queue_id",
+ .type = TEAM_OPTION_TYPE_U32,
+ .per_port = true,
+ .getter = team_queue_id_option_get,
+ .setter = team_queue_id_option_set,
+ },
};
static struct lock_class_key team_netdev_xmit_lock_key;
@@ -1180,6 +1331,9 @@ static int team_init(struct net_device *dev)
for (i = 0; i < TEAM_PORT_HASHENTRIES; i++)
INIT_HLIST_HEAD(&team->en_port_hlist[i]);
INIT_LIST_HEAD(&team->port_list);
+ err = team_queue_override_init(team);
+ if (err)
+ goto err_team_queue_override_init;
team_adjust_ops(team);
@@ -1195,6 +1349,8 @@ static int team_init(struct net_device *dev)
return 0;
err_options_register:
+ team_queue_override_fini(team);
+err_team_queue_override_init:
free_percpu(team->pcpu_stats);
return err;
@@ -1212,6 +1368,7 @@ static void team_uninit(struct net_device *dev)
__team_change_mode(team, NULL); /* cleanup */
__team_options_unregister(team, team_options, ARRAY_SIZE(team_options));
+ team_queue_override_fini(team);
mutex_unlock(&team->lock);
}
@@ -1241,10 +1398,12 @@ static int team_close(struct net_device *dev)
static netdev_tx_t team_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct team *team = netdev_priv(dev);
- bool tx_success = false;
+ bool tx_success;
unsigned int len = skb->len;
- tx_success = team->ops.transmit(team, skb);
+ tx_success = team_queue_override_transmit(team, skb);
+ if (!tx_success)
+ tx_success = team->ops.transmit(team, skb);
if (tx_success) {
struct team_pcpu_stats *pcpu_stats;
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 06495b3..33fcc20 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -68,6 +68,8 @@ struct team_port {
#endif
s32 priority; /* lower number ~ higher priority */
+ u16 queue_id;
+ struct list_head qom_list; /* node in queue override mapping list */
long mode_priv[0];
};
@@ -200,6 +202,8 @@ struct team {
const struct team_mode *mode;
struct team_mode_ops ops;
+ bool queue_override_enabled;
+ struct list_head *qom_lists; /* array of queue override mapping lists */
long mode_priv[TEAM_MODE_PRIV_LONGS];
};
--
1.7.10.4
^ permalink raw reply related
* [patch net-next 3/4] team: add per port priority option
From: Jiri Pirko @ 2012-07-27 16:28 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet
In-Reply-To: <1343406535-22388-1-git-send-email-jiri@resnulli.us>
Allow userspace to set port priority.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/team/team.c | 25 +++++++++++++++++++++++++
include/linux/if_team.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 70752e6..a30b7c1 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1092,6 +1092,24 @@ static int team_user_linkup_en_option_set(struct team *team,
return 0;
}
+static int team_priority_option_get(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->info->port;
+
+ ctx->data.s32_val = port->priority;
+ return 0;
+}
+
+static int team_priority_option_set(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->info->port;
+
+ port->priority = ctx->data.s32_val;
+ return 0;
+}
+
static const struct team_option team_options[] = {
{
.name = "mode",
@@ -1120,6 +1138,13 @@ static const struct team_option team_options[] = {
.getter = team_user_linkup_en_option_get,
.setter = team_user_linkup_en_option_set,
},
+ {
+ .name = "priority",
+ .type = TEAM_OPTION_TYPE_S32,
+ .per_port = true,
+ .getter = team_priority_option_get,
+ .setter = team_priority_option_set,
+ },
};
static struct lock_class_key team_netdev_xmit_lock_key;
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index e5571c4..06495b3 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -67,6 +67,7 @@ struct team_port {
struct netpoll *np;
#endif
+ s32 priority; /* lower number ~ higher priority */
long mode_priv[0];
};
--
1.7.10.4
^ permalink raw reply related
* [patch net-next 2/4] team: add signed 32-bit team option type
From: Jiri Pirko @ 2012-07-27 16:28 UTC (permalink / raw)
To: netdev; +Cc: davem, edumazet
In-Reply-To: <1343406535-22388-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/team/team.c | 12 ++++++++++++
include/linux/if_team.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 87707ab..70752e6 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1787,6 +1787,12 @@ static int team_nl_fill_one_option_get(struct sk_buff *skb, struct team *team,
nla_put_flag(skb, TEAM_ATTR_OPTION_DATA))
goto nest_cancel;
break;
+ case TEAM_OPTION_TYPE_S32:
+ if (nla_put_u8(skb, TEAM_ATTR_OPTION_TYPE, NLA_S32))
+ goto nest_cancel;
+ if (nla_put_s32(skb, TEAM_ATTR_OPTION_DATA, ctx.data.s32_val))
+ goto nest_cancel;
+ break;
default:
BUG();
}
@@ -1975,6 +1981,9 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
case NLA_FLAG:
opt_type = TEAM_OPTION_TYPE_BOOL;
break;
+ case NLA_S32:
+ opt_type = TEAM_OPTION_TYPE_S32;
+ break;
default:
goto team_put;
}
@@ -2031,6 +2040,9 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
case TEAM_OPTION_TYPE_BOOL:
ctx.data.bool_val = attr_data ? true : false;
break;
+ case TEAM_OPTION_TYPE_S32:
+ ctx.data.s32_val = nla_get_s32(attr_data);
+ break;
default:
BUG();
}
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 6960fc1..e5571c4 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -130,6 +130,7 @@ enum team_option_type {
TEAM_OPTION_TYPE_STRING,
TEAM_OPTION_TYPE_BINARY,
TEAM_OPTION_TYPE_BOOL,
+ TEAM_OPTION_TYPE_S32,
};
struct team_option_inst_info {
@@ -146,6 +147,7 @@ struct team_gsetter_ctx {
u32 len;
} bin_val;
bool bool_val;
+ s32 s32_val;
} data;
struct team_option_inst_info *info;
};
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox