* Re: If bridge have no sub-interfaces, it's status may be still with 'RUNNING'
From: yzhu1 @ 2015-02-16 4:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Wu, Kuaikuai, Tao, Yue
In-Reply-To: <20150213133056.3944c13e@uryu.home.lan>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
Hi, Stephen
Follow your advice, I made a new patch. This patch will turn off
carrier when a new bridge interface is created. Please comment on it.
Thanks a lot.
Zhu Yanjun
On 02/14/2015 02:30 AM, Stephen Hemminger wrote:
> On Fri, 13 Feb 2015 17:57:45 +0800
> yzhu1 <Yanjun.Zhu@windriver.com> wrote:
>
>> Hi, all
>>
>> I made this test on ubuntu 14.04 with kernel 3,19-rc7:
>>
>> 1. brctl addbr br0
>>
>> 2. ifconfig br0 up
>>
>> 3. ifconfig br0 (br0's status is with 'RUNNING')
>>
>> 4. brctl addif br0 eth0
>>
>> 5. brctl delif br0 eth0
>>
>> 6. ifconfig br0 (br0's status is without 'RUNNING')
>>
>> When there is no sub-interface, the flag "RUNNING" is missing after the
>> last sub-interface is removed.
>>
>> As such, should we keep "RUNNING" flag after the last sub-interface is
>> removed?
> This is intentional. If there are no active ports in bridge, then
> we want to tell applications that packets will go nowhere.
>
>
[-- Attachment #2: 0001-bridge-turn-off-carrier-when-the-bridge-is-created.patch --]
[-- Type: text/x-patch, Size: 998 bytes --]
>From e03af5263bcaeea15442601e2a9f65c6b582352b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Mon, 16 Feb 2015 12:45:36 +0800
Subject: [PATCH 1/1] bridge: turn off carrier when the bridge is created
When a bridge interface is created, there is no any sub interface
in it. In this case, the packets should not go to this bridge interface.
As such, carrier is turned off.
Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
net/bridge/br_device.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index ffd379d..2d60474 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -394,4 +394,9 @@ void br_dev_setup(struct net_device *dev)
br_netfilter_rtable_init(br);
br_stp_timer_init(br);
br_multicast_init(br);
+
+ /* Shutdown bridge to avoid packets */
+ if (netif_carrier_ok(dev)) {
+ netif_carrier_off(dev);
+ }
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/5] virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined.
From: Michael S. Tsirkin @ 2015-02-16 5:14 UTC (permalink / raw)
To: Rusty Russell; +Cc: lkml, netdev@vger.kernel.org
In-Reply-To: <87twytb9by.fsf@rustcorp.com.au>
> struct virtio_net_hdr hdr;
> __virtio16 num_buffers; /* Number of merged rx buffers */
> };
> +#else /* ... VIRTIO_NET_NO_LEGACY */
> +/*
> + * This header comes first in the scatter-gather list. If you don't
> + * specify GSO or CSUM features, you can simply ignore the header.
> + *
> + * This is bitwise-equivalent to the legacy struct virtio_net_hdr_mrg_rxbuf.
I would add "but with all fields squashed into the main structure".
> + */
> +struct virtio_net_hdr_v1 {
> +#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> +#define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> + __u8 flags;
> +#define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> +#define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> +#define VIRTIO_NET_HDR_GSO_UDP 3 /* GSO frame, IPv4 UDP (UFO) */
> +#define VIRTIO_NET_HDR_GSO_TCPV6 4 /* GSO frame, IPv6 TCP */
> +#define VIRTIO_NET_HDR_GSO_ECN 0x80 /* TCP has ECN set */
> + __u8 gso_type;
> + __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
> + __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
> + __virtio16 csum_start; /* Position to start checksumming from */
> + __virtio16 csum_offset; /* Offset after that to place checksum */
> + __virtio16 num_buffers; /* Number of merged rx buffers */
> +};
> +#endif /* ...VIRTIO_NET_NO_LEGACY */
I note that this way host code can't be structured like this:
struct virtio_net_hdr_v1 modern;
/* handle modern guests */
....
#ifndef VIRTIO_NET_NO_LEGACY
struct virtio_net_hdr_mrg_rxbuf mrg;
/* handle legacy guests */
#endif
Define virtio_net_hdr_v1 unconditionally?
> /*
> * Control virtqueue data structures
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipv4: Raise tcp PMTU probe mss base size
From: Fan Du @ 2015-02-16 5:15 UTC (permalink / raw)
To: yzhu1; +Cc: Fan Du, davem, netdev
In-Reply-To: <54DDC8B1.1050307@windriver.com>
于 2015年02月13日 17:49, yzhu1 写道:
> backward compatible? :-D
yes, it will be auto tuned back in black hole detecting path.
Also user could adjust the base size through /proc/sys/net/ipv4/tcp_base_mss
for optimal configuration.
> Zhu Yanjun
> On 02/13/2015 04:16 PM, Fan Du wrote:
>> Quotes from RFC4821 7.2. Selecting Initial Values
>>
>> It is RECOMMENDED that search_low be initially set to an MTU size
>> that is likely to work over a very wide range of environments. Given
>> today's technologies, a value of 1024 bytes is probably safe enough.
>> The initial value for search_low SHOULD be configurable.
>>
>> Moreover, set a small value will introduce extra time for the search
>> to converge. So set the initial probe base mss size to 1024 Bytes.
>>
>> Signed-off-by: Fan Du <fan.du@intel.com>
>> ---
^ permalink raw reply
* Re: [PATCH net-next 2/3] ipv4: Use binary search to choose tcp PMTU probe_size
From: Fan Du @ 2015-02-16 5:27 UTC (permalink / raw)
To: John Heffner; +Cc: Fan Du, David Miller, Netdev
In-Reply-To: <CABrhC0mPhY1u5rb=KsaF96fLqw_QYLUGm_D9_Yhn655JxLN1Xw@mail.gmail.com>
于 2015年02月14日 01:52, John Heffner 写道:
> On Fri, Feb 13, 2015 at 3:16 AM, Fan Du <fan.du@intel.com> wrote:
>> Current probe_size is chosen by doubling mss_cache,
>> the initial mss base is 512 Bytes, as a result the
>> converged probe_size will only be 1024 Bytes, there
>> is still big gap between 1024 and common 1500 bytes
>> of mtu.
>>
>> Use binary search to choose probe_size in a fine
>> granularity manner, an optimal mss will be found
>> to boost performance as its maxmium.
>>
>> Test env:
>> Docker instance with vxlan encapuslation(82599EB)
>> iperf -c 10.0.0.24 -t 60
>>
>> before this patch:
>> 1.26 Gbits/sec
>>
>> After this patch: increase 26%
>> 1.59 Gbits/sec
>>
>> Signed-off-by: Fan Du <fan.du@intel.com>
>
> Thanks for looking into making mtu probing better. Improving the
> search strategy is commendable. One high level comment though is that
> there's some cost associated with probing and diminishing returns the
> smaller the interval (search_high - search_low), so there should be
> some threshold below which further probing is deemed no longer useful.
>
> Aside from that, some things in this patch don't look right to me.
> Comments inline below.
>
>
>> ---
>> include/net/inet_connection_sock.h | 3 +++
>> net/ipv4/tcp_input.c | 5 ++++-
>> net/ipv4/tcp_output.c | 12 +++++++++---
>> net/ipv4/tcp_timer.c | 2 +-
>> 4 files changed, 17 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
>> index 5976bde..3d0932e 100644
>> --- a/include/net/inet_connection_sock.h
>> +++ b/include/net/inet_connection_sock.h
>> @@ -124,6 +124,9 @@ struct inet_connection_sock {
>> int search_high;
>> int search_low;
>>
>> + int search_high_sav;
>> + int search_low_sav;
>> +
>> /* Information on the current probe. */
>> int probe_size;
>> } icsk_mtup;
>
>
> What are these for? They're assigned but not used.
It's used by the probe timer to restore original search range.
See patch3/3.
>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 8fdd27b..20b28e9 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -2613,7 +2613,10 @@ static void tcp_mtup_probe_success(struct sock *sk)
>> tp->snd_cwnd_stamp = tcp_time_stamp;
>> tp->snd_ssthresh = tcp_current_ssthresh(sk);
>>
>> - icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
>> + if (icsk->icsk_mtup.search_low == icsk->icsk_mtup.probe_size)
>> + icsk->icsk_mtup.search_low = icsk->icsk_mtup.search_high;
>> + else
>> + icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
>> icsk->icsk_mtup.probe_size = 0;
>> tcp_sync_mss(sk, icsk->icsk_pmtu_cookie);
>> }
>
> It would be cleaner to handle this in tcp_mtu_probe, in deciding
> whether to issue a probe, than to change the semantics of search_high
> and search_low. Issuing a probe where probe_size == search_low seems
> like the wrong thing to do.
That's my original thoughts, the seconds thoughts is every BYTE in datacenter
cost money, so why not to get optimal performance by using every possible byte
available.
Anyway, a sysctl threshold will also do the job, will incorporate this in next version.
>
>> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> index a2a796c..0a60deb 100644
>> --- a/net/ipv4/tcp_output.c
>> +++ b/net/ipv4/tcp_output.c
>> @@ -1349,10 +1349,13 @@ void tcp_mtup_init(struct sock *sk)
>> struct inet_connection_sock *icsk = inet_csk(sk);
>> struct net *net = sock_net(sk);
>>
>> - icsk->icsk_mtup.enabled = net->ipv4.sysctl_tcp_mtu_probing > 1;
>> + icsk->icsk_mtup.enabled = net->ipv4.sysctl_tcp_mtu_probing;
>> icsk->icsk_mtup.search_high = tp->rx_opt.mss_clamp + sizeof(struct tcphdr) +
>> icsk->icsk_af_ops->net_header_len;
>> icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, net->ipv4.sysctl_tcp_base_mss);
>> +
>> + icsk->icsk_mtup.search_high_sav = icsk->icsk_mtup.search_high;
>> + icsk->icsk_mtup.search_low_sav = icsk->icsk_mtup.search_low;
>> icsk->icsk_mtup.probe_size = 0;
>> }
>> EXPORT_SYMBOL(tcp_mtup_init);
>
> You're changing the meaning of sysctl_tcp_mtu_probing. I don't think
> that's what you want. From Documentation/networking/ip-sysctl.txt:
>
> tcp_mtu_probing - INTEGER
> Controls TCP Packetization-Layer Path MTU Discovery. Takes three
> values:
> 0 - Disabled
> 1 - Disabled by default, enabled when an ICMP black hole detected
> 2 - Always enabled, use initial MSS of tcp_base_mss.
yes, will honor the original enable theme.
>
>> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>> index 0732b78..9d1cfe0 100644
>> --- a/net/ipv4/tcp_timer.c
>> +++ b/net/ipv4/tcp_timer.c
>> @@ -113,7 +113,7 @@ static void tcp_mtu_probing(struct inet_connection_sock *icsk, struct sock *sk)
>> struct tcp_sock *tp = tcp_sk(sk);
>> int mss;
>>
>> - mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low) >> 1;
>> + mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low);
>> mss = min(net->ipv4.sysctl_tcp_base_mss, mss);
>> mss = max(mss, 68 - tp->tcp_header_len);
>> icsk->icsk_mtup.search_low = tcp_mss_to_mtu(sk, mss);
>
> Why did you change this? I think this breaks black hole detection.
hmm, I misunderstood this part.
In case of pure black hole detection, lowering the current tcp mss instead of search_low,
will make more sense, as current tcp mss still got lost.
- mss = tcp_mtu_to_mss(sk, icsk->icsk_mtup.search_low) >> 1;
+ /* try mss smaller than current mss */
+ mss = tcp_current_mss(sk) >> 1;
Black hole seems more like a misconfiguration in administrative level on intermediate node,
rather than a stack issue, why keep shrinking mss to get packet through with poor performance?
> Thanks,
> -John
>
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: Create probe timer for tcp PMTU as per RFC4821
From: Fan Du @ 2015-02-16 5:28 UTC (permalink / raw)
To: Ying Xue; +Cc: Fan Du, davem, netdev
In-Reply-To: <54DDCB11.5050304@windriver.com>
于 2015年02月13日 17:59, Ying Xue 写道:
>> +static void icsk_mtup_probe_timer(unsigned long arg)
>> >+{
>> >+ struct sock *sk = (struct sock *)arg;
>> >+ struct net *net = sock_net(sk);
>> >+ struct inet_connection_sock *icsk = inet_csk(sk);
>> >+
>> >+ /* Restore orignal search range */
>> >+ icsk->icsk_mtup.search_high = icsk->icsk_mtup.search_high_sav;
>> >+ icsk->icsk_mtup.search_low = icsk->icsk_mtup.search_low_sav;
>> >+ icsk->icsk_mtup.probe_size = 0;
>> >+}
>> >+
> As icsk_mtup_probe_timer() is run asynchronously, we may touch an invalid socket
> instance if we don't hold socket's refcount before launching the timer.
>
> Therefore, in general we use the standard interfaces like sk_reset_timer() and
> sk_stop_timer() to operate timers associated with socket. So, the usage about
> timer in the patch seems unsafe for us. For instance, you can study how
> icsk_retransmit_timer, icsk_delack_timer and sk_timer, are implemented.
right, socket layer has stander API wrapper to manipulate timers like you point out.
Thanks for the notice :)
> Regards,
> Ying
>
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: Create probe timer for tcp PMTU as per RFC4821
From: Fan Du @ 2015-02-16 5:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Fan Du, davem, netdev
In-Reply-To: <1423830709.4942.17.camel@edumazet-glaptop2.roam.corp.google.com>
于 2015年02月13日 20:31, Eric Dumazet 写道:
> On Fri, 2015-02-13 at 16:16 +0800, Fan Du wrote:
>> >As per RFC4821 7.3. Selecting Probe Size, a probe timer should
>> >be armed once probing has converged. Once this timer expired,
>> >probing again to take advantage of any path PMTU change. The
>> >recommended probing interval is 10 minutes per RFC1981.
>> >
>> >Signed-off-by: Fan Du<fan.du@intel.com>
>> >---
>> > include/net/inet_connection_sock.h | 2 ++
>> > include/net/netns/ipv4.h | 1 +
>> > include/net/tcp.h | 3 +++
>> > net/ipv4/sysctl_net_ipv4.c | 7 +++++++
>> > net/ipv4/tcp.c | 2 ++
>> > net/ipv4/tcp_ipv4.c | 1 +
>> > net/ipv4/tcp_output.c | 23 ++++++++++++++++++++++-
>> > 7 files changed, 38 insertions(+), 1 deletions(-)
>> >
>> >diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
>> >index 3d0932e..e78e5ab 100644
>> >--- a/include/net/inet_connection_sock.h
>> >+++ b/include/net/inet_connection_sock.h
>> >@@ -126,6 +126,8 @@ struct inet_connection_sock {
>> >
>> > int search_high_sav;
>> > int search_low_sav;
>> >+
>> >+ struct timer_list probe_timer;
>> >
> We certainly wont add yet another timer in tcp socket for such usage.
>
> And a buggy one, since you forgot all the refcounting associated with
> such timers.
oh, embarrassing...
Will place probe timer aside with icsk_delack_timer in struct inet_connection_sock,
and manipulate through sk_reset_timer.
Thanks for the reviewing.
^ permalink raw reply
* work with
From: Eijzenga MMEM, Esmee @ 2015-02-16 5:57 UTC (permalink / raw)
My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust you with a business worth 8.3 million USD? Please reply ONLY to my private email: mgatan@rogers.com for more information.
^ permalink raw reply
* Re: [PATCH 3/5] virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined.
From: Rusty Russell @ 2015-02-16 6:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: lkml, netdev@vger.kernel.org
In-Reply-To: <20150216051435.GA14616@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
>> struct virtio_net_hdr hdr;
>> __virtio16 num_buffers; /* Number of merged rx buffers */
>> };
>> +#else /* ... VIRTIO_NET_NO_LEGACY */
>> +/*
>> + * This header comes first in the scatter-gather list. If you don't
>> + * specify GSO or CSUM features, you can simply ignore the header.
>> + *
>> + * This is bitwise-equivalent to the legacy struct virtio_net_hdr_mrg_rxbuf.
>
> I would add "but with all fields squashed into the main structure".
Yep.
>> + */
>> +struct virtio_net_hdr_v1 {
>> +#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
>> +#define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
>> + __u8 flags;
>> +#define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
>> +#define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
>> +#define VIRTIO_NET_HDR_GSO_UDP 3 /* GSO frame, IPv4 UDP (UFO) */
>> +#define VIRTIO_NET_HDR_GSO_TCPV6 4 /* GSO frame, IPv6 TCP */
>> +#define VIRTIO_NET_HDR_GSO_ECN 0x80 /* TCP has ECN set */
>> + __u8 gso_type;
>> + __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
>> + __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
>> + __virtio16 csum_start; /* Position to start checksumming from */
>> + __virtio16 csum_offset; /* Offset after that to place checksum */
>> + __virtio16 num_buffers; /* Number of merged rx buffers */
>> +};
>> +#endif /* ...VIRTIO_NET_NO_LEGACY */
>
> I note that this way host code can't be structured like this:
>
>
> struct virtio_net_hdr_v1 modern;
> /* handle modern guests */
> ....
>
> #ifndef VIRTIO_NET_NO_LEGACY
> struct virtio_net_hdr_mrg_rxbuf mrg;
> /* handle legacy guests */
>
> #endif
>
>
> Define virtio_net_hdr_v1 unconditionally?
Thanks, that's a good idea! Here's the incremental:
virtio_net: unconditionally define struct virtio_net_hdr_v1.
This was introduced in commit ed9ecb0415b97b5f9f91f146e1977bb372c74c6d,
but only defined if !VIRTIO_NET_NO_LEGACY. We should always define
it: easier for users to have conditional legacy code.
Suggested-by: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index 4a9b58113d6e..7bbee79ca293 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -74,39 +74,12 @@ struct virtio_net_config {
__u16 max_virtqueue_pairs;
} __attribute__((packed));
-#ifndef VIRTIO_NET_NO_LEGACY
-/* This header comes first in the scatter-gather list.
- * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
- * be the first element of the scatter-gather list. If you don't
- * specify GSO or CSUM features, you can simply ignore the header. */
-struct virtio_net_hdr {
-#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 // Use csum_start, csum_offset
-#define VIRTIO_NET_HDR_F_DATA_VALID 2 // Csum is valid
- __u8 flags;
-#define VIRTIO_NET_HDR_GSO_NONE 0 // Not a GSO frame
-#define VIRTIO_NET_HDR_GSO_TCPV4 1 // GSO frame, IPv4 TCP (TSO)
-#define VIRTIO_NET_HDR_GSO_UDP 3 // GSO frame, IPv4 UDP (UFO)
-#define VIRTIO_NET_HDR_GSO_TCPV6 4 // GSO frame, IPv6 TCP
-#define VIRTIO_NET_HDR_GSO_ECN 0x80 // TCP has ECN set
- __u8 gso_type;
- __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
- __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
- __virtio16 csum_start; /* Position to start checksumming from */
- __virtio16 csum_offset; /* Offset after that to place checksum */
-};
-
-/* This is the version of the header to use when the MRG_RXBUF
- * feature has been negotiated. */
-struct virtio_net_hdr_mrg_rxbuf {
- struct virtio_net_hdr hdr;
- __virtio16 num_buffers; /* Number of merged rx buffers */
-};
-#else /* ... VIRTIO_NET_NO_LEGACY */
/*
* This header comes first in the scatter-gather list. If you don't
* specify GSO or CSUM features, you can simply ignore the header.
*
- * This is bitwise-equivalent to the legacy struct virtio_net_hdr_mrg_rxbuf.
+ * This is bitwise-equivalent to the legacy struct virtio_net_hdr_mrg_rxbuf,
+ * only flattened.
*/
struct virtio_net_hdr_v1 {
#define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
@@ -124,6 +97,29 @@ struct virtio_net_hdr_v1 {
__virtio16 csum_offset; /* Offset after that to place checksum */
__virtio16 num_buffers; /* Number of merged rx buffers */
};
+
+#ifndef VIRTIO_NET_NO_LEGACY
+/* This header comes first in the scatter-gather list.
+ * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it must
+ * be the first element of the scatter-gather list. If you don't
+ * specify GSO or CSUM features, you can simply ignore the header. */
+struct virtio_net_hdr {
+ /* See VIRTIO_NET_HDR_F_* */
+ __u8 flags;
+ /* See VIRTIO_NET_HDR_GSO_* */
+ __u8 gso_type;
+ __virtio16 hdr_len; /* Ethernet + IP + tcp/udp hdrs */
+ __virtio16 gso_size; /* Bytes to append to hdr_len per frame */
+ __virtio16 csum_start; /* Position to start checksumming from */
+ __virtio16 csum_offset; /* Offset after that to place checksum */
+};
+
+/* This is the version of the header to use when the MRG_RXBUF
+ * feature has been negotiated. */
+struct virtio_net_hdr_mrg_rxbuf {
+ struct virtio_net_hdr hdr;
+ __virtio16 num_buffers; /* Number of merged rx buffers */
+};
#endif /* ...VIRTIO_NET_NO_LEGACY */
/*
^ permalink raw reply related
* Re: [PATCH net-next 0/6] bpf: Enable BPF JIT on ppc32
From: Denis Kirjanov @ 2015-02-16 7:13 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linuxppc-dev, benh, mpe, ast
In-Reply-To: <54E0FCEF.6090701@iogearbox.net>
On 2/15/15, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 02/15/2015 07:06 PM, Denis Kirjanov wrote:
>> This patch series enables BPF JIT on ppc32. There are relatevily
>> few chnages in the code to make it work.
>>
>> All test_bpf tests passed both on 7447a and P2041-based machines.
>
> I'm just wondering, next to the feedback that has already been
> provided, would opening this up for ppc32 make it significantly
> more difficult in future to migrate from classic BPF JIT to eBPF
> JIT eventually (which is what we want long-term)? Being curious,
> is there any ongoing effort from ppc people?
>
Well, I don't see significant challenges to enable eBPF on ppc64 in the future.
I'll start working on it after I get this merged
^ permalink raw reply
* Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-02-16 7:34 UTC (permalink / raw)
To: Kalle Valo, Arend van Spriel
Cc: Pat Erley, brudley-dY08KVG/lbpWk0Htik3J/w, Franky Lin,
meuleman-dY08KVG/lbpWk0Htik3J/w, linville-2XuSBdqkA4R54TAoqtyWWQ,
pieterpg-dY08KVG/lbpWk0Htik3J/w, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
wens-jdAy2FN1RRM, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <878ufzi5s3.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 2015/2/15 22:54, Kalle Valo wrote:
> Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
>
>> On 02/15/15 04:27, Pat Erley wrote:
>>> On 02/14/2015 08:40 PM, Fu, Zhonghui wrote:
>>>> Any comments to this patch? Can it be accepted?
>> I assume that patches are queued up until after the merge window that
>> we are currently in.
> That's right. In the future I will most likely apply patches also during
> the merge window, but as I'm still a greenhorn I'll be on the safe and
> wait for the merge window to end.
I am very glad to see this.
Could you please tell which release candidate this patch will be likely merged into now?
Thanks,
Zhonghui
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v1 00/10] Add network namespace support in the RDMA-CM
From: Shachar Raindel @ 2015-02-16 8:10 UTC (permalink / raw)
To: Shachar Raindel, roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Liran Liss,
Guy Shapiro, Haggai Eran, Yotam Kenneth
In-Reply-To: <1423667204-8807-1-git-send-email-raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Sean,
Have you looked at this patch set?
Do you have any comments as for the changes done in the CM?
Thanks,
--Shachar
> -----Original Message-----
> From: Shachar Raindel [mailto:raindel-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org]
> Sent: Wednesday, February 11, 2015 5:07 PM
> To: roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Liran Liss; Guy
> Shapiro; Haggai Eran; Yotam Kenneth; Shachar Raindel
> Subject: [PATCH v1 00/10] Add network namespace support in the RDMA-CM
>
> RDMA-CM uses IP based addressing and routing to setup RDMA connections
> between
> hosts. Currently, all of the IP interfaces and addresses used by the
> RDMA-CM
> must reside in the init_net namespace. This restricts the usage of
> containers
> with RDMA to only work with host network namespace (aka the kernel
> init_net NS
> instance).
>
> This patchset allows using network namespaces with the RDMA-CM.
>
> Each RDMA-CM and CM id is keeping a reference to a network namespace.
>
> This reference is based on the process network namespace at the time of
> the
> creation of the object or inherited from the listener.
>
> This network namespace is used to perform all IP and network related
> operations. Specifically, the local device lookup, as well as the remote
> GID
> address resolution are done in the context of the RDMA-CM object's
> namespace.
> This allows outgoing connections to reach the right target, even if the
> same
> IP address exists in multiple network namespaces. This can happen if
> each
> network namespace resides on a different pkey.
>
> Additionally, the network namespace is used to split the listener
> service ID
> table. From the user point of view, each network namespace has a unique,
> completely independent table of service IDs. This allows running
> multiple
> instances of a single service on the same machine, using containers. To
> implement this, the CM layer now parses the IP address from the CM
> connect
> requests, and searches for the matching networking device. The namespace
> of
> the device found is used when looking up the service ID in the listener
> table.
>
> The functionnality introduced by this series would come into play when
> the
> transport is InfiniBand and IPoIB interfaces are assigned to each
> namespace.
> Multiple IPoIB interfaces can be created and assigned to different RDMA-
> CM
> capable containers, for example using pipework [1].
>
> Full support for RoCE will be introduced in a later stage.
>
> The patches apply against kernel v3.19-rc5, with the patch "RDMA/CMA:
> Mark
> IPv4 addresses correctly when the listener is IPv6" [2] applied.
>
> The patchset is structured as follows:
>
> Patches 1 and 2 are relatively trivial API extensions, requiring the
> callers
> of certain ib_addr and ib_core functions to provide a network namespace,
> as
> needed.
>
> Patches 3 and 4 adds the ability to lookup a network namespace according
> to
> the IP address, device and pkey. It finds the matching IPoIB interfaces,
> and
> safely takes a reference on the network namespace before returning to
> the
> caller.
>
> Patch 5 moves the logic that extracts the IP address from a connect
> request
> into the CM layer. This is needed for the upcoming listener lookup by
> namespace.
>
> Patch 6 adds support for network namespaces in the CM layer. All callers
> are
> still passing init_net as the namespace, to maintain backward
> compatibility.
> For incoming requests, the namespace of the relevant IPoIB device is
> used.
>
> Patches 7 and 8 add proper namespace support to the RDMA-CM module.
>
> Patches 9 and 10 add namespace support to the relevant user facing
> modules in
> the IB stack.
>
>
> [1] https://github.com/jpetazzo/pipework/pull/108
> [2] https://patchwork.kernel.org/patch/5298971/
>
> Change-log:
>
> V0 -> V1:
> - Fix code review comments by Yann
> - Rebase on top of linux-3.19
>
> Guy Shapiro (7):
> IB/addr: Pass network namespace as a parameter
> IB/core: Pass network namespace as a parameter to relevant functions
> IB/ipoib: Return IPoIB devices as possible matches to
> get_net_device_by_port_pkey_ip
> IB/cm,cma: Move RDMA IP CM private-data parsing code from ib_cma to
> ib_cm
> IB/cm: Add network namespace support
> IB/cma: Add support for network namespaces
> IB/ucma: Take the network namespace from the process
>
> Shachar Raindel (1):
> IB/ucm: Add partial support for network namespaces
>
> Yotam Kenneth (2):
> IB/core: Find the network namespace matching connection parameters
> IB/cma: Separate port allocation to network namespaces
>
> drivers/infiniband/core/addr.c | 31 +-
> drivers/infiniband/core/agent.c | 4 +-
> drivers/infiniband/core/cm.c | 287
> ++++++++++++++++--
> drivers/infiniband/core/cma.c | 332 +++++++++-----
> -------
> drivers/infiniband/core/device.c | 57 ++++
> drivers/infiniband/core/mad_rmpp.c | 10 +-
> drivers/infiniband/core/ucm.c | 4 +-
> drivers/infiniband/core/ucma.c | 4 +-
> drivers/infiniband/core/user_mad.c | 4 +-
> drivers/infiniband/core/verbs.c | 22 +-
> drivers/infiniband/hw/ocrdma/ocrdma_ah.c | 3 +-
> drivers/infiniband/ulp/ipoib/ipoib_cm.c | 21 +-
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 122 +++++++-
> drivers/infiniband/ulp/iser/iser_verbs.c | 2 +-
> drivers/infiniband/ulp/isert/ib_isert.c | 2 +-
> drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
> drivers/infiniband/ulp/srpt/ib_srpt.c | 5 +-
> .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h | 4 +-
> include/rdma/ib_addr.h | 44 ++-
> include/rdma/ib_cm.h | 63 +++-
> include/rdma/ib_verbs.h | 44 ++-
> include/rdma/rdma_cm.h | 6 +-
> net/9p/trans_rdma.c | 2 +-
> net/rds/ib.c | 2 +-
> net/rds/ib_cm.c | 2 +-
> net/rds/iw.c | 2 +-
> net/rds/iw_cm.c | 2 +-
> net/rds/rdma_transport.c | 2 +-
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 2 +-
> net/sunrpc/xprtrdma/verbs.c | 3 +-
> 30 files changed, 822 insertions(+), 268 deletions(-)
>
> --
> 1.7.11.2
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
From: Arend van Spriel @ 2015-02-16 9:35 UTC (permalink / raw)
To: Fu, Zhonghui
Cc: Kalle Valo, Pat Erley, brudley, Franky Lin, meuleman, linville,
pieterpg, hdegoede, wens, linux-wireless, brcm80211-dev-list,
netdev, linux-kernel@vger.kernel.org
In-Reply-To: <54E19DA1.4030407@linux.intel.com>
On 02/16/15 08:34, Fu, Zhonghui wrote:
>
> On 2015/2/15 22:54, Kalle Valo wrote:
>> Arend van Spriel<arend@broadcom.com> writes:
>>
>>> On 02/15/15 04:27, Pat Erley wrote:
>>>> On 02/14/2015 08:40 PM, Fu, Zhonghui wrote:
>>>>> Any comments to this patch? Can it be accepted?
>>> I assume that patches are queued up until after the merge window that
>>> we are currently in.
>> That's right. In the future I will most likely apply patches also during
>> the merge window, but as I'm still a greenhorn I'll be on the safe and
>> wait for the merge window to end.
> I am very glad to see this.
> Could you please tell which release candidate this patch will be likely merged into now?
For which tree are you asking this? When the merge window ends and
linus' tree has moved to 3.20-rc1, the wireless-drivers-next will move
to that -rc1 as well and pending/accepted patches will be applied for
the next kernel release. If you are asking when they will be in linus'
tree than the answer is 3.21-rc1. Now if you say this patch solves a
real problem for you (providing usual proof like log with stack trace)
you can request it to go on the wireless-drivers tree to be fixed for 3.20.
Regards,
Arend
^ permalink raw reply
* udp6_tunnel and address scope?
From: Erik Hugne @ 2015-02-16 9:38 UTC (permalink / raw)
To: netdev; +Cc: ying.xue
It looks like the ipv6 udp tunnel interface is missing scopeid. In a TIPC
patchset i'm working on, i worked around this by manually constructing the
sockaddr_in6 and binding this address to the v6 socket. But it may be worth
considering to add sin6_scopeid to struct udp_port_cfg.
//E
^ permalink raw reply
* RE: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
From: David Laight @ 2015-02-16 9:50 UTC (permalink / raw)
To: 'Fu, Zhonghui', Kalle Valo, brudley@broadcom.com,
Arend van Spriel, Franky Lin, meuleman@broadcom.com,
linville@tuxdriver.com, pieterpg@broadcom.com,
hdegoede@redhat.com, wens@csie.org,
linux-wireless@vger.kernel.org, brcm80211-dev-list@broadcom.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <54E0072D.3020802@linux.intel.com>
> > WiFi chip has 2 SDIO functions, and PM core will trigger
> > twice suspend/resume operations for one WiFi chip to do
> > the same things. This patch avoid this case.
Do you want to suspend on the first or last request?
In general it might be that one function is in use and
something wants to suspend the other (as inactive).
If they suspend together you might need to pretend the
first function is suspended but only do the real power-saving
device suspend when all the functions have been suspended.
David
^ permalink raw reply
* Re: vnet problem (bug? feature?)
From: Toerless Eckert @ 2015-02-16 10:13 UTC (permalink / raw)
To: Sowmini Varadhan; +Cc: Bill Fink, Cong Wang, netdev
In-Reply-To: <CACP96tRBPy4cakmJY_K9zrYbgWLgNfxDo4inrH8qV6pgRtR-1g@mail.gmail.com>
On Sun, Feb 15, 2015 at 04:16:21PM -0500, Sowmini Varadhan wrote:
> RPF != strong/weak ES models defined in Section 3.3.4.2 of rfc1122.
Agreed on the RFC definition, but not on the model. RP filtering makes
it more difficult, if not impossible to a weak-host. Consider the multi-homed
host that's attached such that it would receive packets for one of its addresses
from different interfaces. RP filtering throws away those packet from all but
one interface (just talking unicast hee for the sake of the argument).
> RPF is about ingress filtering (rfc 3704) and verifying that the return
> path to the src addr of the packet would go out on the same interface
> it came on. The wiki page on Reverse_path_forwarding has some detail.
rfc3704 does mention multicast only on the side, so i would claim Fred did
primarily think about unicast, and the whole text is also targeted for ISPs
== routers, not for RPF filtering on actual multi homed hosts.
Of course, RPF filtering for multicast has been traditionally used in
almost all relevant routing protocols, but again: thats only on routers,
and AFAIK in the distant past not on MHH.
I fail to find a good reference explaining why linux would default to
rp_filtering = 1 (more appropriate for routers) even if forwarding defaults to 0
(more appropriate for multi-homed hosts).
Any ideas how to track back where this choice came from ?
Thanks!
Toerless
> --Sowmini
> --
> 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
--
---
Toerless.Eckert@informatik.uni-erlangen.de
/C=de/A=d400/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless/
^ permalink raw reply
* Attempt to auto-load em_cmp.ko results in negative module refcnt
From: Ignacy Gawedzki @ 2015-02-16 10:59 UTC (permalink / raw)
To: netdev
Hi,
This simple test case
tc qdisc add dev eth0 root handle 1: htb
tc class add dev eth0 root classid 1: htb rate 1Gbit
tc class add dev eth0 parent 1: classid 1:1 htb rate 1Gbit
tc filter add dev eth0 parent 1: basic match 'cmp(u8 at 0 eq 0)' classid 1:1
fails with the following
RTNETLINK answers: No such file or directory
We have an error talking to the kernel
if em_cmp.ko is not loaded beforehand.
After that, lsmod shows that em_cmp.ko is loaded indeed, but its usage count
is -1 and an attempd to unload the module results in a "BUG at
kernel/module.c:752".
This has been broken pretty recently, I'm currently attempting a git bisect on
this.
--
Ignacy Gawędzki
R&D Engineer
Green Communications
^ permalink raw reply
* Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: He Kuang @ 2015-02-16 11:26 UTC (permalink / raw)
To: Alexei Starovoitov, Steven Rostedt
Cc: Ingo Molnar, Namhyung Kim, Arnaldo Carvalho de Melo, Jiri Olsa,
Masami Hiramatsu, Linux API, Network Development, LKML,
Linus Torvalds, Peter Zijlstra, Eric W. Biederman, wangnan0
In-Reply-To: <CAMEtUuzY_Po=WtFEFg1aqzJ8dEF4rHGcWDsaS44KYgACMNPPgA@mail.gmail.com>
Hi, Alexei
Another suggestion on bpf syscall interface. Currently, BPF +
syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
case, bpf bytecode cannot be loaded to the kernel.
If we turn the functionality of BPF_SYSCALL into a loadable module, then
we can use it without any dependencies on the kernel. What about change
bpf syscall to a /dev node or /sys file which can be exported by a
kernel module?
^ permalink raw reply
* Re: [PATCH v2 1/7] rtlwifi: Remove unused defines from rtl8192cu driver
From: Sergei Shtylyov @ 2015-02-16 11:58 UTC (permalink / raw)
To: Priit Laes, Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1424033211-11696-2-git-send-email-plaes@plaes.org>
Hello.
You didn't sign off on the patches, so they can't be applied.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 2/9] be2net: replace (1 << x) with BIT(x)
From: Sergei Shtylyov @ 2015-02-16 12:09 UTC (permalink / raw)
To: Sathya Perla, netdev
In-Reply-To: <1423228723-10919-3-git-send-email-sathya.perla@emulex.com>
Hello.
On 2/6/2015 4:18 PM, Sathya Perla wrote:
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
> BIT(x) is the preffered usage.
Preferred.
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
[...]
> diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
> index 3b1d59d..9869556 100644
> --- a/drivers/net/ethernet/emulex/benet/be.h
> +++ b/drivers/net/ethernet/emulex/benet/be.h
> @@ -361,15 +361,15 @@ enum vf_state {
> ASSIGNED = 1
> };
>
> -#define BE_FLAGS_LINK_STATUS_INIT 1
> -#define BE_FLAGS_SRIOV_ENABLED (1 << 2)
> -#define BE_FLAGS_WORKER_SCHEDULED (1 << 3)
> -#define BE_FLAGS_VLAN_PROMISC (1 << 4)
> -#define BE_FLAGS_MCAST_PROMISC (1 << 5)
> -#define BE_FLAGS_NAPI_ENABLED (1 << 9)
> -#define BE_FLAGS_QNQ_ASYNC_EVT_RCVD (1 << 11)
> -#define BE_FLAGS_VXLAN_OFFLOADS (1 << 12)
> -#define BE_FLAGS_SETUP_DONE (1 << 13)
> +#define BE_FLAGS_LINK_STATUS_INIT BIT(1)
Not BIT(0)?
> +#define BE_FLAGS_SRIOV_ENABLED BIT(2)
> +#define BE_FLAGS_WORKER_SCHEDULED BIT(3)
> +#define BE_FLAGS_VLAN_PROMISC BIT(4)
> +#define BE_FLAGS_MCAST_PROMISC BIT(5)
> +#define BE_FLAGS_NAPI_ENABLED BIT(6)
> +#define BE_FLAGS_QNQ_ASYNC_EVT_RCVD BIT(7)
> +#define BE_FLAGS_VXLAN_OFFLOADS BIT(8)
> +#define BE_FLAGS_SETUP_DONE BIT(9)
So, you decided to renumber the bits?
[...]
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv4: Create probe timer for tcp PMTU as per RFC4821
From: Eric Dumazet @ 2015-02-16 12:19 UTC (permalink / raw)
To: Fan Du; +Cc: Fan Du, davem, netdev
In-Reply-To: <54E18263.8040002@gmail.com>
On Mon, 2015-02-16 at 13:38 +0800, Fan Du wrote:
> 于 2015年02月13日 20:31, Eric Dumazet 写道:
> > We certainly wont add yet another timer in tcp socket for such usage.
> >
> > And a buggy one, since you forgot all the refcounting associated with
> > such timers.
>
> oh, embarrassing...
> Will place probe timer aside with icsk_delack_timer in struct inet_connection_sock,
> and manipulate through sk_reset_timer.
No : I said we would _not_ accept yet another timer (ie a big structure)
for such very rare event.
You can implement a pseudo timer, using a simple u32 field, that you
test in tcp_mtu_probe() to clear icsk->icsk_mtup.probe_size when enough
time has elapsed.
(tcp_time_stamp is u32, so are tp->lsndtime, tp->snd_cwnd_stamp,
tp->rcv_tstamp, tp->retrans_stamp, tp->tso_deferred, ...)
^ permalink raw reply
* Re: [PATCHv2] ath9k_htc: add adaptive usb receive flow control to repair soft lockup with monitor mode
From: Oleksij Rempel @ 2015-02-16 12:25 UTC (permalink / raw)
To: Yuwei Zheng, linux-kernel, ath9k-devel, linux-wireless, kvalo,
ath9k-devel
Cc: netdev
In-Reply-To: <1423528464-8433-1-git-send-email-yuweizheng@139.com>
[-- Attachment #1.1: Type: text/plain, Size: 15659 bytes --]
Do every one OK with this patch? I think this one is the last version?
Am 10.02.2015 um 01:34 schrieb Yuwei Zheng:
> The ath9k_hif_usb_rx_cb function excute on the interrupt context, and ath9k_rx_tasklet excute
> on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more chance to excute than
> ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is always full,
> and the do {}while(true) loop will not be break. The kernel get a soft lockup panic.
>
> [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
> [kworker/0:0:30609]
> [59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.858522] Kernel panic - not syncing: softlockup: hung tasks
>
> [59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
> [59014.046834] bc20: de57b950 60000113
> [59014.059579] bc40: 00000000 bb32bb32 60000113 de57b948 de57b500 dc7bb440 df4bbcd0 00000000
> [59014.072337] bc60: de57b950 60000113 df4bbcd0 df4bbc80 c04c259d c04c25a0 60000133 ffffffff
> [59014.085233] [<c04c28db>] (__irq_svc+0x3b/0x5c) from [<c04c25a0>] (_raw_spin_unlock_irqrestore+0xc/0x10)
> [59014.100437] [<c04c25a0>] (_raw_spin_unlock_irqrestore+0xc/0x10) from [<bf9c2089>] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
> [59014.118267] [<bf9c2089>] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from [<c0036d23>] (tasklet_action+0x3b/0x98)
> [59014.134132] [<c0036d23>] (tasklet_action+0x3b/0x98) from [<c0036709>] (__do_softirq+0x99/0x16c)
> [59014.147784] [<c0036709>] (__do_softirq+0x99/0x16c) from [<c00369f7>] (irq_exit+0x5b/0x5c)
> [59014.160653] [<c00369f7>] (irq_exit+0x5b/0x5c) from [<c000cfc3>] (handle_IRQ+0x37/0x78)
> [59014.173124] [<c000cfc3>] (handle_IRQ+0x37/0x78) from [<c00085df>] (omap3_intc_handle_irq+0x5f/0x68)
> [59014.187225] [<c00085df>] (omap3_intc_handle_irq+0x5f/0x68) from [<c04c28db>](__irq_svc+0x3b/0x5c)
>
> This bug can be see with low performance board, such as uniprocessor beagle bone board. Add some debug
> message in the ath9k_hif_usb_rx_cb function may trigger this bug quickly.
>
> Signed-off-by: Yuwei Zheng <yuweizheng@139.com>
> ---
> Changes since v1:
> - Add aurfc_active flag to stop delayed submit while ath9k_hif_usb_dealloc_rx_urbs called.
> - Add spinlock aurfc_lock to protect aurfc_delayed_work and aurfc_active.
> - Add mod_delayed_work to trigger aurfc_submit_handler excuted immediately while rx_buf list is empty.
> - Add flush_delayed_work to wait the aurfc_submit_handler finish.
>
> drivers/net/wireless/ath/ath9k/hif_usb.c | 78 +++++++++++++++++++++++---
> drivers/net/wireless/ath/ath9k/hif_usb.h | 13 +++++
> drivers/net/wireless/ath/ath9k/htc.h | 19 +++++++
> drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 53 +++++++++++++++++
> drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 58 +++++++++++++++++++
> 5 files changed, 214 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 8e7153b..2e73e19 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> struct hif_device_usb *hif_dev =
> usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
> int ret;
> + int delay;
>
> if (!skb)
> return;
> @@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> default:
> goto resubmit;
> }
> -
> if (likely(urb->actual_length != 0)) {
> skb_put(skb, urb->actual_length);
> ath9k_hif_usb_rx_stream(hif_dev, skb);
> @@ -667,12 +667,23 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> resubmit:
> skb_reset_tail_pointer(skb);
> skb_trim(skb, 0);
> -
> - usb_anchor_urb(urb, &hif_dev->rx_submitted);
> - ret = usb_submit_urb(urb, GFP_ATOMIC);
> - if (ret) {
> - usb_unanchor_urb(urb);
> - goto free;
> + spin_lock(&hif_dev->aurfc_lock);
> + /* submit the urb more slowly for flow control */
> + if (atomic_read(&hif_dev->aurfc_submit_delay) > 0 &&
> + hif_dev->aurfc_active == 1) {
> + usb_anchor_urb(urb, &hif_dev->rx_delayed_submitted);
> + delay = atomic_read(&hif_dev->aurfc_submit_delay);
> + schedule_delayed_work(&hif_dev->aurfc_delayed_work,
> + msecs_to_jiffies(delay));
> + spin_unlock(&hif_dev->aurfc_lock);
> + } else {
> + spin_unlock(&hif_dev->aurfc_lock);
> + usb_anchor_urb(urb, &hif_dev->rx_submitted);
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret) {
> + usb_unanchor_urb(urb);
> + goto free;
> + }
> }
>
> return;
> @@ -818,9 +829,53 @@ err:
> return -ENOMEM;
> }
>
> +static void aurfc_submit_handler(struct work_struct *work)
> +{
> + struct hif_device_usb *hif_dev =
> + container_of(work,
> + struct hif_device_usb,
> + aurfc_delayed_work.work);
> + struct urb *urb = NULL;
> + struct sk_buff *skb = NULL;
> + int ret;
> + int loop_times = 0;
> +
> + AURFC_STAT_INC(aurfc_called);
> + while (true) {
> + loop_times++;
> + if (loop_times > MAX_RX_URB_NUM)
> + atomic_add(AURFC_STEP,
> + &hif_dev->aurfc_submit_delay);
> +
> + urb = usb_get_from_anchor(
> + &hif_dev->rx_delayed_submitted);
> + if (urb) {
> + skb = (struct sk_buff *)urb->context;
> + ret = usb_submit_urb(urb, GFP_KERNEL);
> + if (ret != 0) {
> + usb_unanchor_urb(urb);
> + dev_kfree_skb_any(skb);
> + urb->context = NULL;
> + }
> + } else {
> + break;
> + }
> + }
> +}
> +
> static void ath9k_hif_usb_dealloc_rx_urbs(struct hif_device_usb *hif_dev)
> {
> + unsigned long flags;
> +
> + spin_lock_irqsave(&hif_dev->aurfc_lock, flags);
> + hif_dev->aurfc_active = 0;
> + /* excute the last queued work immediately */
> + mod_delayed_work(system_wq, &hif_dev->aurfc_delayed_work, 0);
> + spin_unlock_irqrestore(&hif_dev->aurfc_lock, flags);
> + /* wait the last work finish, otherwise kill urbs may deadlock*/
> + flush_delayed_work(&hif_dev->aurfc_delayed_work);
> usb_kill_anchored_urbs(&hif_dev->rx_submitted);
> + usb_kill_anchored_urbs(&hif_dev->rx_delayed_submitted);
> }
>
> static int ath9k_hif_usb_alloc_rx_urbs(struct hif_device_usb *hif_dev)
> @@ -830,8 +885,17 @@ static int ath9k_hif_usb_alloc_rx_urbs(struct hif_device_usb *hif_dev)
> int i, ret;
>
> init_usb_anchor(&hif_dev->rx_submitted);
> + init_usb_anchor(&hif_dev->rx_delayed_submitted);
> +
> spin_lock_init(&hif_dev->rx_lock);
>
> + /* add for adaptive usb receive flow control*/
> + atomic_set(&hif_dev->aurfc_submit_delay, 0);
> + INIT_DELAYED_WORK(&hif_dev->aurfc_delayed_work,
> + aurfc_submit_handler);
> + spin_lock_init(&hif_dev->aurfc_lock);
> + hif_dev->aurfc_active = 1;
> +
> for (i = 0; i < MAX_RX_URB_NUM; i++) {
>
> /* Allocate URB */
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.h b/drivers/net/wireless/ath/ath9k/hif_usb.h
> index 51496e7..2ff59be 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.h
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
> @@ -41,6 +41,7 @@
> #define MAX_RX_URB_NUM 8
> #define MAX_RX_BUF_SIZE 16384
> #define MAX_PKT_NUM_IN_TRANSFER 10
> +#define AURFC_STEP 70 /* millisecond */
>
> #define MAX_REG_OUT_URB_NUM 1
> #define MAX_REG_IN_URB_NUM 64
> @@ -98,9 +99,21 @@ struct hif_device_usb {
> struct hif_usb_tx tx;
> struct usb_anchor regout_submitted;
> struct usb_anchor rx_submitted;
> + /* anchor delayed urb */
> + struct usb_anchor rx_delayed_submitted;
> struct usb_anchor reg_in_submitted;
> struct usb_anchor mgmt_submitted;
> struct sk_buff *remain_skb;
> +
> + /* adaptive usb receive flow control */
> + struct delayed_work aurfc_delayed_work;
> + /* to protect the delayed work */
> + spinlock_t aurfc_lock;
> + /* urb submit delay, in millisecond */
> + atomic_t aurfc_submit_delay;
> + /* set to 1, if the urb can be delayed submit */
> + int aurfc_active;
> +
> const char *fw_name;
> int rx_remain_len;
> int rx_pkt_len;
> diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
> index 9dde265..1586bd2 100644
> --- a/drivers/net/wireless/ath/ath9k/htc.h
> +++ b/drivers/net/wireless/ath/ath9k/htc.h
> @@ -331,6 +331,13 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct sk_buff *skb)
>
> #define TX_QSTAT_INC(q) (priv->debug.tx_stats.queue_stats[q]++)
>
> +#define AURFC_STAT_INC(c) \
> + (hif_dev->htc_handle->drv_priv->debug.aurfc_stats.c++)
> +#define AURFC_STAT_ADD(c, a) \
> + (hif_dev->htc_handle->drv_priv->debug.aurfc_stats.c += a)
> +#define AURFC_STAT_SET(c, a) \
> + (hif_dev->htc_handle->drv_priv->debug.aurfc_stats.c = a)
> +
> void ath9k_htc_err_stat_rx(struct ath9k_htc_priv *priv,
> struct ath_rx_status *rs);
>
> @@ -352,11 +359,20 @@ struct ath_skbrx_stats {
> u32 skb_dropped;
> };
>
> +struct ath_aurfc_stats {
> + u32 aurfc_highwater;
> + u32 aurfc_lowwater;
> + u32 aurfc_wm_triggered;
> + u32 aurfc_submit_delay;
> + u32 aurfc_called;
> +};
> +
> struct ath9k_debug {
> struct dentry *debugfs_phy;
> struct ath_tx_stats tx_stats;
> struct ath_rx_stats rx_stats;
> struct ath_skbrx_stats skbrx_stats;
> + struct ath_aurfc_stats aurfc_stats;
> };
>
> void ath9k_htc_get_et_strings(struct ieee80211_hw *hw,
> @@ -377,6 +393,9 @@ void ath9k_htc_get_et_stats(struct ieee80211_hw *hw,
>
> #define TX_QSTAT_INC(c) do { } while (0)
>
> +#define AURFC_STAT_INC(c) do {} while (0)
> +#define AURFC_STAT_ADD(c, a) do {} while (0)
> +#define AURFC_STAT_SET(c, a) do {} while (0)
> static inline void ath9k_htc_err_stat_rx(struct ath9k_htc_priv *priv,
> struct ath_rx_status *rs)
> {
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
> index 8cef1ed..a6be9be 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c
> @@ -286,6 +286,54 @@ static const struct file_operations fops_skb_rx = {
> .llseek = default_llseek,
> };
>
> +static ssize_t read_file_aurfc(struct file *file,
> + char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath9k_htc_priv *priv = file->private_data;
> + char *buf;
> + unsigned int len = 0, size = 1500;
> + ssize_t retval = 0;
> +
> + buf = kzalloc(size, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + len += scnprintf(buf + len, size - len,
> + "%20s : %10u\n", "High watermark",
> + priv->debug.aurfc_stats.aurfc_highwater);
> + len += scnprintf(buf + len, size - len,
> + "%20s : %10u\n", "Low watermark",
> + priv->debug.aurfc_stats.aurfc_lowwater);
> +
> + len += scnprintf(buf + len, size - len,
> + "%20s : %10u\n", "WM triggered",
> + priv->debug.aurfc_stats.aurfc_wm_triggered);
> +
> + len += scnprintf(buf + len, size - len,
> + "%20s : %10u\n", "Handler called",
> + priv->debug.aurfc_stats.aurfc_called);
> +
> + len += scnprintf(buf + len, size - len,
> + "%20s : %10u\n", "Submit delay",
> + priv->debug.aurfc_stats.aurfc_submit_delay);
> + if (len > size)
> + len = size;
> +
> + retval = simple_read_from_buffer(user_buf, count,
> + ppos, buf, len);
> + kfree(buf);
> +
> + return retval;
> +}
> +
> +static const struct file_operations fops_aurfc = {
> + .read = read_file_aurfc,
> + .open = simple_open,
> + .owner = THIS_MODULE,
> + .llseek = default_llseek,
> +};
> +
> static ssize_t read_file_slot(struct file *file, char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> @@ -518,7 +566,12 @@ int ath9k_htc_init_debug(struct ath_hw *ah)
> debugfs_create_file("skb_rx", S_IRUSR, priv->debug.debugfs_phy,
> priv, &fops_skb_rx);
>
> + debugfs_create_file("aurfc_stats", S_IRUSR,
> + priv->debug.debugfs_phy,
> + priv, &fops_aurfc);
> +
> ath9k_cmn_debug_recv(priv->debug.debugfs_phy, &priv->debug.rx_stats);
> +
> ath9k_cmn_debug_phy_err(priv->debug.debugfs_phy, &priv->debug.rx_stats);
>
> debugfs_create_file("slot", S_IRUSR, priv->debug.debugfs_phy,
> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
> index a0f58e2..1c8ebc5 100644
> --- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
> @@ -1061,7 +1061,31 @@ void ath9k_rx_tasklet(unsigned long data)
> unsigned long flags;
> struct ieee80211_hdr *hdr;
>
> + /* add for adaptive usb receive flow control*/
> + int looptimes = 0;
> + int highwatermark = ATH9K_HTC_RXBUF*3/4;
> + int lowwatermark = ATH9K_HTC_RXBUF/32;
> + unsigned int delay = 0;
> +
> + struct htc_target *htc = priv->htc;
> + struct hif_device_usb *hif_dev = htc->hif_dev;
> +
> + AURFC_STAT_SET(aurfc_highwater, highwatermark);
> + AURFC_STAT_SET(aurfc_lowwater, lowwatermark);
> +
> do {
> + looptimes++;
> + /* when trigger high wartermark, tell the
> + * urb callback to submit more slowlly.
> + */
> + if (looptimes > highwatermark) {
> + delay = looptimes*AURFC_STEP;
> + atomic_set(&hif_dev->aurfc_submit_delay,
> + delay);
> + AURFC_STAT_INC(aurfc_wm_triggered);
> + AURFC_STAT_SET(aurfc_submit_delay, delay);
> + }
> +
> spin_lock_irqsave(&priv->rx.rxbuflock, flags);
> list_for_each_entry(tmp_buf, &priv->rx.rxbuf, list) {
> if (tmp_buf->in_process) {
> @@ -1072,6 +1096,29 @@ void ath9k_rx_tasklet(unsigned long data)
>
> if (rxbuf == NULL) {
> spin_unlock_irqrestore(&priv->rx.rxbuflock, flags);
> + spin_lock_irqsave(&hif_dev->aurfc_lock,
> + flags);
> + /* the rxbuf list is empty now, the
> + * queued work could be scheduled
> + * to submit urbs immediately.
> + */
> + if (atomic_read(
> + &hif_dev->aurfc_submit_delay) > 0 &&
> + hif_dev->aurfc_active > 0)
> + mod_delayed_work(system_wq,
> + &hif_dev->aurfc_delayed_work,
> + 0);
> + spin_unlock_irqrestore(&hif_dev->aurfc_lock,
> + flags);
> + /* reset submit delay to guaranteed
> + * usb receive performance.
> + */
> + if (looptimes < lowwatermark) {
> + atomic_set(&hif_dev->aurfc_submit_delay
> + , 0);
> + AURFC_STAT_SET(aurfc_submit_delay,
> + 0);
> + }
> break;
> }
>
> @@ -1114,6 +1161,10 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
> struct ath_common *common = ath9k_hw_common(ah);
> struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
>
> + struct htc_target *htc = priv->htc;
> + struct hif_device_usb *hif_dev = htc->hif_dev;
> + int delay = ATH9K_HTC_RXBUF * AURFC_STEP;
> +
> spin_lock(&priv->rx.rxbuflock);
> list_for_each_entry(tmp_buf, &priv->rx.rxbuf, list) {
> if (!tmp_buf->in_process) {
> @@ -1124,6 +1175,13 @@ void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
> spin_unlock(&priv->rx.rxbuflock);
>
> if (rxbuf == NULL) {
> + /* The rxbuf list is full now, tell the urb callback
> + * to submit more slowly. Otherwise, the soft lockup
> + * may be triggerd immediately.
> + */
> + atomic_set(&hif_dev->aurfc_submit_delay, delay);
> + AURFC_STAT_INC(aurfc_wm_triggered);
> + AURFC_STAT_SET(aurfc_submit_delay, delay);
> ath_dbg(common, ANY, "No free RX buffer\n");
> goto err;
> }
>
--
Regards,
Oleksij
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: [PATCH net-next] net: Reflect RX hash for transmit
From: Eric Dumazet @ 2015-02-16 12:29 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1424025438-1659-1-git-send-email-therbert@google.com>
On Sun, 2015-02-15 at 10:37 -0800, Tom Herbert wrote:
> This patch allows a driver to request that the receive hash it provides
> to the stack is reflected back in skb->hash for packets transmitted
> on the associated connection. The hash value returned by a device could
> have meaning when used in transmit to identify a flow, for instance
> the hash may by a flow ID for a flow created in a (virtual) device.
> With the flow ID provided on transmit this can obviate the need
> to create the hash and do the lookup on the fly in transmit.
>
> Note that this is an opportunistic optimization, there is no
> separate negotiation between the stack and driver/device for
> the hash used in either TX or RX.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
It is not clear to me why we would want to consume yet another skb->bit
for this.
This seems it might be a socket attribute, rather than a device provided
one on every packet.
Anyway, this seems a premature change, as no driver currently needs this
yet ?
^ permalink raw reply
* RE: [PATCH net-next 2/9] be2net: replace (1 << x) with BIT(x)
From: Sathya Perla @ 2015-02-16 12:55 UTC (permalink / raw)
To: Sergei Shtylyov, netdev@vger.kernel.org
In-Reply-To: <54E1DDF4.5040901@cogentembedded.com>
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sergei.shtylyov@cogentembedded.com]
>
> Hello.
>
> On 2/6/2015 4:18 PM, Sathya Perla wrote:
>
> > From: Vasundhara Volam <vasundhara.volam@emulex.com>
>
> > BIT(x) is the preffered usage.
>
> Preferred.
:-) As this is a harmless spelling mistake only in the changelog,
I'll not bother sending a new patch for this!
>
> [...]
>
> > diff --git a/drivers/net/ethernet/emulex/benet/be.h
> b/drivers/net/ethernet/emulex/benet/be.h
> > index 3b1d59d..9869556 100644
> > --- a/drivers/net/ethernet/emulex/benet/be.h
> > +++ b/drivers/net/ethernet/emulex/benet/be.h
> > @@ -361,15 +361,15 @@ enum vf_state {
> > ASSIGNED = 1
> > };
> >
> > -#define BE_FLAGS_LINK_STATUS_INIT 1
> > -#define BE_FLAGS_SRIOV_ENABLED (1 << 2)
> > -#define BE_FLAGS_WORKER_SCHEDULED (1 << 3)
> > -#define BE_FLAGS_VLAN_PROMISC (1 << 4)
> > -#define BE_FLAGS_MCAST_PROMISC (1 << 5)
> > -#define BE_FLAGS_NAPI_ENABLED (1 << 9)
> > -#define BE_FLAGS_QNQ_ASYNC_EVT_RCVD (1 << 11)
> > -#define BE_FLAGS_VXLAN_OFFLOADS (1 << 12)
> > -#define BE_FLAGS_SETUP_DONE (1 << 13)
> > +#define BE_FLAGS_LINK_STATUS_INIT BIT(1)
>
> Not BIT(0)?
Huh, this was not intentional. I'll remember to use bit-0 the next time
we introduce a new bit!
>
> > +#define BE_FLAGS_SRIOV_ENABLED BIT(2)
> > +#define BE_FLAGS_WORKER_SCHEDULED BIT(3)
> > +#define BE_FLAGS_VLAN_PROMISC BIT(4)
> > +#define BE_FLAGS_MCAST_PROMISC BIT(5)
> > +#define BE_FLAGS_NAPI_ENABLED BIT(6)
> > +#define BE_FLAGS_QNQ_ASYNC_EVT_RCVD BIT(7)
> > +#define BE_FLAGS_VXLAN_OFFLOADS BIT(8)
> > +#define BE_FLAGS_SETUP_DONE BIT(9)
>
> So, you decided to renumber the bits?
Yes, some holes in the bit map were removed.
^ permalink raw reply
* [PATCH v3 0/7] rtlwifi: Unused #define removal
From: Priit Laes @ 2015-02-16 12:59 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Priit Laes
Hi all,
This is v3 of the rtlwifi unused #define cleanup patchset.
No changes since v2 except added Signed-off-by.
Changes since v1:
- Rebase patches against wireless-driver-next tree.
Priit Laes (7):
rtlwifi: Remove unused defines from rtl8192cu driver
rtlwifi: Remove unused defines from driver-specific def.h
rtlwifi: Remove unused RF6052_MAX_REG define
rtlwifi: Remove unused defines from cam.h
rtlwifi: Remove unused defines from base.h
rtlwifi: Remove unused defines from efuse.h
rtlwifi: Remove unused RTL_SUPPORTED_CTRL_FILTER define
drivers/net/wireless/rtlwifi/base.h | 6 ----
drivers/net/wireless/rtlwifi/cam.h | 2 --
drivers/net/wireless/rtlwifi/core.h | 2 --
drivers/net/wireless/rtlwifi/efuse.h | 6 ----
drivers/net/wireless/rtlwifi/rtl8188ee/def.h | 41 ----------------------------
drivers/net/wireless/rtlwifi/rtl8188ee/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8192ce/def.h | 41 ----------------------------
drivers/net/wireless/rtlwifi/rtl8192ce/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 2 --
drivers/net/wireless/rtlwifi/rtl8192cu/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 39 --------------------------
drivers/net/wireless/rtlwifi/rtl8192ee/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8192se/def.h | 1 -
drivers/net/wireless/rtlwifi/rtl8723ae/def.h | 41 ----------------------------
drivers/net/wireless/rtlwifi/rtl8723ae/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8723be/rf.h | 1 -
drivers/net/wireless/rtlwifi/rtl8821ae/def.h | 41 ----------------------------
drivers/net/wireless/rtlwifi/rtl8821ae/rf.h | 1 -
18 files changed, 229 deletions(-)
--
2.3.0
^ permalink raw reply
* [PATCH v3 1/7] rtlwifi: Remove unused defines from rtl8192cu driver
From: Priit Laes @ 2015-02-16 12:59 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Priit Laes
In-Reply-To: <1424091600-13121-1-git-send-email-plaes@plaes.org>
Signed-off-by: Priit Laes <plaes@plaes.org>
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
index c1e33b0..6758808 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
@@ -32,8 +32,6 @@
#define H2C_RA_MASK 6
-#define LLT_POLLING_LLT_THRESHOLD 20
-#define LLT_POLLING_READY_TIMEOUT_COUNT 100
#define LLT_LAST_ENTRY_OF_TX_PKT_BUFFER 255
#define RX_PAGE_SIZE_REG_VALUE PBP_128
--
2.3.0
^ 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