* Re: [RFC PATCH v1 1/2] net: implement mechanism for HW based QOS
From: John Fastabend @ 2010-11-18 17:31 UTC (permalink / raw)
To: netdev, nhorman, davem
In-Reply-To: <20101117091828.GA14773@canuck.infradead.org>
On 11/17/2010 1:18 AM, Thomas Graf wrote:
> On Tue, Nov 16, 2010 at 09:15:45PM -0800, John Fastabend wrote:
>> This patch provides a mechanism for lower layer devices to
>> steer traffic using skb->priority to tx queues. This allows
>> for hardware based QOS schemes to use the default qdisc without
>> incurring the penalties related to global state and the qdisc
>> lock. While reliably receiving skbs on the correct tx ring
>> to avoid head of line blocking resulting from shuffling in
>> the LLD. Finally, all the goodness from txq caching and xps/rps
>> can still be leveraged.
>
> Nice.
>
>> If this approach seems reasonable I'll go ahead and finish
>> this up. The priority to tc mapping should probably be exposed
>> to userspace either through sysfs or rtnetlink. Any thoughts?
>
> Please use netlink for this and add a new IFLA_ attribute. I
> suggest you put nested attributes into it so you can extend it
> later on and/or obsolete attributes:
>
> [IFLA_TC] = {
> [IFLA_TC_MAX_TCS]
> [IFLA_TC_NUM_TCS]
> [IFLA_TC_TXQCOUNT]
> [IFLA_TC_TXQOFFSET]
> [IFLA_TC_MAP]
> }
>
> Or whatever is reasonable to export to userspace.
Sounds good. I'll do this and post an update.
Thanks,
John.
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: fix a race in IGMP handling
From: David Miller @ 2010-11-18 17:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: sachinp, netdev, linux-s390, linux-next, ursula.braun, fubar
In-Reply-To: <1290075978.2781.36.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Nov 2010 11:26:18 +0100
> Actually this raises an interesting case for bonding as well.
>
> Before my RCU conversion __bond_resend_igmp_join_requests() was unsafe.
>
> For net-next-2.6, it is now safe (RCU is held), but needs a cleanup
> patch to avoid sparse errors.
>
> Thanks
>
> [PATCH net-2.6] bonding: fix a race in IGMP handling
>
> RCU conversion in IGMP code done in net-next-2.6 raised a race in
> __bond_resend_igmp_join_requests().
>
> It iterates in_dev->mc_list without appropriate protection (RTNL, or
> read_lock on in_dev->mc_list_lock).
>
> Another cpu might delete an entry while we use it and trigger a fault.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
Applied, but I'm going to have to be careful and make sure I undo
this the next time I pull net-2.6 into net-next-2.6
Thanks.
^ permalink raw reply
* Re: [net-next] MAINTAINERS: Add stmmac maintainer
From: David Miller @ 2010-11-18 17:32 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1290071942-28179-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Thu, 18 Nov 2010 10:19:02 +0100
> Add STMMAC to the list of supported Ethernet drivers
> and myself as maintainer.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
This sort of thing is fine for net-2.6, so I've put it there.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: IGMP handling cleanup
From: David Miller @ 2010-11-18 17:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: sachinp, netdev, linux-s390, linux-next, ursula.braun, fubar
In-Reply-To: <1290077352.2781.47.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Nov 2010 11:49:12 +0100
> Le jeudi 18 novembre 2010 à 11:26 +0100, Eric Dumazet a écrit :
>
>> Actually this raises an interesting case for bonding as well.
>>
>> Before my RCU conversion __bond_resend_igmp_join_requests() was unsafe.
>>
>> For net-next-2.6, it is now safe (RCU is held), but needs a cleanup
>> patch to avoid sparse errors.
>
> [PATCH net-next-2.6] bonding: IGMP handling cleanup
>
> Instead of iterating in_dev->mc_list from bonding driver, its better
> to call a helper function provided by igmp.c
> Details of implementation (locking) are private to igmp code.
>
> ip_mc_rejoin_group(struct ip_mc_list *im) becomes
> ip_mc_rejoin_groups(struct in_device *in_dev);
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Sachin Sant <sachinp@in.ibm.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] qlge: Fix incorrect usage of module parameters and netdev msg level
From: Ron Mercer @ 2010-11-18 17:22 UTC (permalink / raw)
To: Sonny Rao
Cc: netdev@vger.kernel.org, Milton Miller, Linux Driver,
linux-kernel@vger.kernel.org
In-Reply-To: <1290075903-3038-1-git-send-email-sonnyrao@linux.vnet.ibm.com>
On Thu, Nov 18, 2010 at 02:25:03AM -0800, Sonny Rao wrote:
> Driver appears to be mistaking the permission field with default value
> in the case of debug and qlge_irq_type.
>
> Driver is also passing debug as a bitmask into netif_msg_init()
> which really wants a number of bits, so fix that.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
> ---
> drivers/net/qlge/qlge_main.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/qlge/qlge_main.c b/drivers/net/qlge/qlge_main.c
> index d9a7626..66878bb 100644
> --- a/drivers/net/qlge/qlge_main.c
> +++ b/drivers/net/qlge/qlge_main.c
> @@ -62,15 +62,15 @@ static const u32 default_msg =
> /* NETIF_MSG_PKTDATA | */
> NETIF_MSG_HW | NETIF_MSG_WOL | 0;
>
> -static int debug = 0x00007fff; /* defaults above */
> -module_param(debug, int, 0);
> +static int debug = 15; /* defaults above */
I think what we want here is:
> +static int debug = -1; /* defaults above */
This will correct it and maintain the current behavior.
By passing in the 0x00007ffff we were getting the passed in default
paramter from the 2nd compare in the first if statement below. If we set
debug to 15 then it looks like we would turn on all bits rather than
qlge default.
static inline u32 netif_msg_init(int debug_value, int default_msg_enable_bits)
{
/* use default */
if (debug_value < 0 || debug_value >= (sizeof(u32) * 8))
return default_msg_enable_bits;
if (debug_value == 0) /* no output */
return 0;
/* set low N bits */
return (1 << debug_value) - 1;
}
^ permalink raw reply
* Re: net-next-2.6 [PATCH 0/6]: dccp ccid-2: Ack Vector patch set second/concluding part II
From: David Miller @ 2010-11-18 17:37 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <20101118064200.GA5457@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 18 Nov 2010 07:42:00 +0100
> dccp ccid-2: whitespace fix-up
>
> This fixes whitespace noise introduced in commit "dccp ccid-2: Algorithm to
> update buffer state", 5753fdfe8bd8e9a2ff9e5af19b0ffc78bfcd502a, 14 Nov 2010.
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Applied, but btw your Signed-off-by has trailing whitespace :-)
^ permalink raw reply
* Re: [RFC PATCH v1 1/2] net: implement mechanism for HW based QOS
From: Eric Dumazet @ 2010-11-18 17:39 UTC (permalink / raw)
To: John Fastabend
Cc: netdev@vger.kernel.org, nhorman@tuxdriver.com,
davem@davemloft.net
In-Reply-To: <4CE5621F.8040503@intel.com>
Le jeudi 18 novembre 2010 à 09:27 -0800, John Fastabend a écrit :
> Thanks for the feedback!
>
> num_tx_queues is an unsigned int in net_device and I can't see any
> place that would limit it to 16bits. So I think we need 32 bits here.
> Otherwise I will make these changes and fix the fallout. This is much
> cleaner.
>
>
Hmm...
include/linux/skbuff.h
__u16 queue_mapping:16;
static inline void skb_record_rx_queue(struct sk_buff *skb, u16 rx_queue)
Anyway, we dont want to have more than 32768 queues, not before year
2020 at least
Thanks
^ permalink raw reply
* Re: [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
From: David Miller @ 2010-11-18 17:40 UTC (permalink / raw)
To: penguin-kernel; +Cc: eric.dumazet, netdev
In-Reply-To: <201011180403.oAI43JBT005077@www262.sakura.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Thu, 18 Nov 2010 13:03:19 +0900
>>From a391f571f21bfa81369599f03e86fa75589291a3 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Thu, 18 Nov 2010 12:44:26 +0900
> Subject: [PATCH 2.6.37-rc2] Fix duplicate volatile warning.
>
> jiffies is defined as "volatile".
>
> extern unsigned long volatile __jiffy_data jiffies;
>
> ACCESS_ONCE() uses "volatile".
> As a result, some compilers warn duplicate `volatile' for ACCESS_ONCE(jiffies).
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fair enough, applied, thanks.
^ permalink raw reply
* Re: [net-2.6 PATCH v2] net: zero kobject in rx_queue_release
From: David Miller @ 2010-11-18 17:42 UTC (permalink / raw)
To: john.r.fastabend; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <4CE36F9E.4070508@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Tue, 16 Nov 2010 22:01:02 -0800
> net-next has Tom's changes for queue allocation and freeing. So the
> net-2.6 patch and net-next-2.6 patches are slightly different. I
> wanted to get the RCU_INIT_POINTER update in both and thought it
> would be easiest for Dave if they applied cleanly on both
> tree's. Let me know if there is a better way to indicate that here I
> just used the prefix net and net-next.
Right, applied, thanks everyone.
^ permalink raw reply
* Re: Loopback performance from kernel 2.6.12 to 2.6.37
From: Eric Dumazet @ 2010-11-18 17:41 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, David Miller
In-Reply-To: <1290088353.2781.137.camel@edumazet-laptop>
Le jeudi 18 novembre 2010 à 14:52 +0100, Eric Dumazet a écrit :
> Le mardi 09 novembre 2010 à 15:25 +0100, Eric Dumazet a écrit :
>
> > So far, so good. These are the expected numbers. Now we have to
> > understand why corei7 gets 38 seconds instead of 8 :)
> >
> >
>
> My tests show a problem with backlog processing, and too big TCP
> windows. (at least on loopback and wild senders)
>
> Basically, with huge tcp windows we have now (default 4 Mbytes),
> the reader process can have to process up to 4Mbytes of backlogged data
> in __release_sock() before returning from its 'small' read(fd, buffer,
> 1024) done by netcat.
>
> While it processes this backlog, it sends tcp ACKS, allowing sender to
> send new frames that might be dropped because of sk_rcvqueues_full(), or
> continue to fill receive queue up to the receiver window, feeding the
> task in __release_sock() [loop]
>
>
> This blows cpu caches completely [data is queued, and the dequeue is
> done long after], and latency of a single read() can be very high. This
> blocks the pipeline of user processing eventually.
>
>
> <disgress>
> I also understand why UDP latencies are so impacted. If we receive a
> burst of frames on same socket, the user process reading first frame
> might be forced to process the backlog before returning to userland.
>
> Really we must zap lock_sock() from UDP input path.
>
> commit 95766fff6b9a78d1 ([UDP]: Add memory accounting) was a big error.
> </disgress>
>
>
>
> On my server machine with 6Mbytes of L2 cache, you dont see the problem,
> while on my laptop with 3Mbytes of L2 cache, you can see the problem.
>
> I caught this because of new SNMP counter added in 2.6.34
> (TCPBacklogDrop), that could easily take 1000 increments during the
> test.
>
>
> I built a test program, maybe easier to use than various netcat flavors
> It also use two tasks only, thats better if you have a core 2 Duo like
> me on my laptop ;)
>
> To reproduce the problem, run it with option -l 4M
>
> $ netstat -s|grep TCPBacklogDrop
> TCPBacklogDrop: 788
> $ time ./loopback_transfert -l 1k;netstat -s|grep TCPBacklogDrop
>
> real 0m14.013s
> user 0m0.630s
> sys 0m13.250s
> TCPBacklogDrop: 788
> $ time ./loopback_transfert -l 128k;netstat -s|grep TCPBacklogDrop
>
> real 0m7.447s
> user 0m0.030s
> sys 0m5.490s
> TCPBacklogDrop: 789
> $ time ./loopback_transfert -l 1M;netstat -s|grep TCPBacklogDrop
>
> real 0m11.206s
> user 0m0.020s
> sys 0m7.150s
> TCPBacklogDrop: 793
> $ time ./loopback_transfert -l 4M;netstat -s|grep TCPBacklogDrop
>
> real 0m10.347s
> user 0m0.000s
> sys 0m6.120s
> TCPBacklogDrop: 1510
> $ time ./loopback_transfert -l 16k;netstat -s|grep TCPBacklogDrop
>
> real 0m6.810s
> user 0m0.040s
> sys 0m6.670s
> TCPBacklogDrop: 1511
>
I forgot to include test results for my dev machine (server class
machine, 8 Mbytes of L2 cache) NUMA
2 sockets : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
# netstat -s|grep TCPBacklogDrop
TCPBacklogDrop: 8891
# time ./loopback_transfert -l 16k;netstat -s|grep TCPBacklogDrop
real 0m7.033s
user 0m0.010s
sys 0m4.580s
TCPBacklogDrop: 9239
# time ./loopback_transfert -l 1M;netstat -s|grep TCPBacklogDrop
real 0m5.408s
user 0m0.000s
sys 0m2.880s
TCPBacklogDrop: 9243
# time ./loopback_transfert -l 4M;netstat -s|grep TCPBacklogDrop
real 0m2.965s
user 0m0.000s
sys 0m2.070s
TCPBacklogDrop: 10485
# time ./loopback_transfert -l 6M;netstat -s|grep TCPBacklogDrop
real 0m7.711s
user 0m0.000s
sys 0m3.180s
TCPBacklogDrop: 13537
# time ./loopback_transfert -l 8M;netstat -s|grep TCPBacklogDrop
real 0m11.497s
user 0m0.020s
sys 0m3.830s
TCPBacklogDrop: 17108
As soon as our working set is larger than L2 cache, this is very slow.
for the -l 8M bench :
# Events: 7K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... ................. ...................................
#
40.97% loopback_transf [kernel.kallsyms] [k] copy_user_generic_string
18.57% :8968 [kernel.kallsyms] [k] copy_user_generic_string
3.54% :8968 [kernel.kallsyms] [k] get_page_from_freelist
3.36% :8968 [kernel.kallsyms] [k] tcp_sendmsg
1.17% :8968 [kernel.kallsyms] [k] put_page
0.99% :8968 [kernel.kallsyms] [k] free_hot_cold_page
0.99% :8968 [kernel.kallsyms] [k] __might_sleep
0.88% :8968 [kernel.kallsyms] [k] __ticket_spin_lock
0.81% loopback_transf [kernel.kallsyms] [k] free_pcppages_bulk
0.79% :8968 [kernel.kallsyms] [k] __alloc_pages_nodemask
0.63% loopback_transf [kernel.kallsyms] [k] put_page
0.63% loopback_transf [kernel.kallsyms] [k] __might_sleep
0.63% loopback_transf [kernel.kallsyms] [k] tcp_transmit_skb
0.57% :8968 [kernel.kallsyms] [k] skb_release_data
0.55% loopback_transf [kernel.kallsyms] [k] free_hot_cold_page
0.53% :8968 [kernel.kallsyms] [k] tcp_ack
0.50% loopback_transf [kernel.kallsyms] [k] __inet_lookup_established
0.49% loopback_transf [kernel.kallsyms] [k] skb_copy_datagram_iovec
0.47% :8968 [kernel.kallsyms] [k] __rmqueue
0.45% :8968 [kernel.kallsyms] [k] get_pageblock_flags_group
0.41% :8968 [kernel.kallsyms] [k] zone_watermark_ok
0.41% :8968 [kernel.kallsyms] [k] __inc_zone_state
0.40% loopback_transf [kernel.kallsyms] [k] skb_release_data
0.39% :8968 [kernel.kallsyms] [k] tcp_transmit_skb
^ permalink raw reply
* Re: error while building the kernel Mainline
From: Eric Dumazet @ 2010-11-18 17:48 UTC (permalink / raw)
To: Justin P. Mattock
Cc: linux-net, Linux Kernel Mailing List, netdev, Simon Horman,
Netfilter Development Mailinglist, Patrick McHardy
In-Reply-To: <4CE561A2.2020600@gmail.com>
Le jeudi 18 novembre 2010 à 09:25 -0800, Justin P. Mattock a écrit :
> On 11/18/2010 07:12 AM, Eric Dumazet wrote:
> > Le jeudi 18 novembre 2010 à 06:36 -0800, Justin Mattock a écrit :
> >> hit this yesterday, and havent had time to look at it, to see if its a
> >> simple fix
> >>
> >> MODPOST vmlinux.o
> >> WARNING: modpost: Found 1 section mismatch(es).
> >> To see full details build your kernel with:
> >> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> >> GEN .version
> >> CHK include/generated/compile.h
> >> UPD include/generated/compile.h
> >> CC init/version.o
> >> LD init/built-in.o
> >> LD .tmp_vmlinux1
> >> net/built-in.o: In function `handle_response_icmp':
> >> ip_vs_core.c:(.text+0x2b5c4): undefined reference to `nf_conntrack_untracked'
> >> net/built-in.o: In function `T.925':
> >> ip_vs_core.c:(.text+0x2cbbd): undefined reference to `nf_conntrack_untracked'
> >> net/built-in.o: In function `ip_vs_null_xmit':
> >> (.text+0x310da): undefined reference to `nf_conntrack_untracked'
> >> net/built-in.o: In function `ip_vs_tunnel_xmit':
> >> (.text+0x311e3): undefined reference to `nf_conntrack_untracked'
> >> net/built-in.o: In function `ip_vs_nat_xmit':
> >> (.text+0x3176f): undefined reference to `nf_conntrack_untracked'
> >> net/built-in.o:(.text+0x3199d): more undefined references to
> >> `nf_conntrack_untracked' follow
> >> make: *** [.tmp_vmlinux1] Error 1
> >>
> >> has there been anything sent forward for this yet?
> >>
> >
> > Try to find out why net/netfilter/nf_conntrack_core.c is not compiled ?
>
> seems it is compiling, it's after the compiling when this breaks
>
> >
> > ./net/netfilter/nf_conntrack_core.c:65:DEFINE_PER_CPU(struct nf_conn, nf_conntrack_untracked);
> > ./net/netfilter/nf_conntrack_core.c:66:EXPORT_PER_CPU_SYMBOL(nf_conntrack_untracked);
> >
> >
> >
> >
>
> Justin P. Mattock
Let me guess...
net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
statically (in vmlinux) ?
CONFIG_NF_CONNTRACK=m
CONFIG_IP_VS=y
We probably need some Kconfig magic ;)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Loopback performance from kernel 2.6.12 to 2.6.37
From: David Miller @ 2010-11-18 17:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: jdb, netdev, lawrence
In-Reply-To: <1290102113.2781.237.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Nov 2010 18:41:53 +0100
> Le jeudi 18 novembre 2010 à 14:52 +0100, Eric Dumazet a écrit :
>> Le mardi 09 novembre 2010 à 15:25 +0100, Eric Dumazet a écrit :
>>
>> My tests show a problem with backlog processing, and too big TCP
>> windows. (at least on loopback and wild senders)
>>
>> Basically, with huge tcp windows we have now (default 4 Mbytes),
>> the reader process can have to process up to 4Mbytes of backlogged data
>> in __release_sock() before returning from its 'small' read(fd, buffer,
>> 1024) done by netcat.
>>
>> While it processes this backlog, it sends tcp ACKS, allowing sender to
>> send new frames that might be dropped because of sk_rcvqueues_full(), or
>> continue to fill receive queue up to the receiver window, feeding the
>> task in __release_sock() [loop]
>>
>>
>> This blows cpu caches completely [data is queued, and the dequeue is
>> done long after], and latency of a single read() can be very high. This
>> blocks the pipeline of user processing eventually.
Thanks for looking into this Eric.
We definitely need some kind of choke point so that TCP never
significantly exceeds the congestion window point at which throughput
stops increasing (and only latency does).
One idea is that when we integrate Lawrence Brakmo's TCP-NV congestion
control algorithm, we can try enabling it by default over loopback.
Loopback is kind of an interesting case of the problem scenerio
Lawrence is trying to solve.
^ permalink raw reply
* Re: ethtool 2.6.36 released
From: David Miller @ 2010-11-18 17:49 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, jeff
In-Reply-To: <1290041901.30433.119.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 18 Nov 2010 00:58:21 +0000
> Jeff Garzik has handed over ongoing maintenance to me. Jeff, thanks for
> all your work on ethtool over the past 10 years and for your help with
> making this release.
Indeed, thanks a lot to Jeff for maintaining ethtool all these years.
And thanks to Ben for taking on this task.
^ permalink raw reply
* Re: error while building the kernel Mainline
From: David Miller @ 2010-11-18 17:50 UTC (permalink / raw)
To: eric.dumazet
Cc: justinmattock, linux-net, linux-kernel, netdev, horms,
netfilter-devel, kaber
In-Reply-To: <1290102497.2781.242.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Nov 2010 18:48:17 +0100
> Let me guess...
>
> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
> statically (in vmlinux) ?
>
> CONFIG_NF_CONNTRACK=m
> CONFIG_IP_VS=y
>
> We probably need some Kconfig magic ;)
Randy Dunlap made a similar report today with a sample .config
that triggers the problem.
I'll look into it after lunch.
^ permalink raw reply
* Re: [RFC PATCH v1 1/2] net: implement mechanism for HW based QOS
From: John Fastabend @ 2010-11-18 18:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, nhorman@tuxdriver.com,
davem@davemloft.net
In-Reply-To: <1290101963.2781.234.camel@edumazet-laptop>
On 11/18/2010 9:39 AM, Eric Dumazet wrote:
> Le jeudi 18 novembre 2010 à 09:27 -0800, John Fastabend a écrit :
>
>> Thanks for the feedback!
>>
>> num_tx_queues is an unsigned int in net_device and I can't see any
>> place that would limit it to 16bits. So I think we need 32 bits here.
>> Otherwise I will make these changes and fix the fallout. This is much
>> cleaner.
>>
>>
>
> Hmm...
>
> include/linux/skbuff.h
>
> __u16 queue_mapping:16;
>
>
> static inline void skb_record_rx_queue(struct sk_buff *skb, u16 rx_queue)
>
> Anyway, we dont want to have more than 32768 queues, not before year
> 2020 at least
>
> Thanks
>
>
>
Ah a u16 it is then. And more then 32768 queues would be a bit much.
^ permalink raw reply
* Re: error while building the kernel Mainline
From: Patrick McHardy @ 2010-11-18 18:12 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, justinmattock, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <20101118.095046.28818361.davem@davemloft.net>
Am 18.11.2010 18:50, schrieb David Miller:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 18 Nov 2010 18:48:17 +0100
>
>> Let me guess...
>>
>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>> statically (in vmlinux) ?
>>
>> CONFIG_NF_CONNTRACK=m
>> CONFIG_IP_VS=y
>>
>> We probably need some Kconfig magic ;)
>
> Randy Dunlap made a similar report today with a sample .config
> that triggers the problem.
>
> I'll look into it after lunch.
Thanks, I'll take care of this.
^ permalink raw reply
* Re: error while building the kernel Mainline
From: Justin P. Mattock @ 2010-11-18 18:13 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, linux-net, linux-kernel, netdev, horms,
netfilter-devel, kaber
In-Reply-To: <20101118.095046.28818361.davem@davemloft.net>
On 11/18/2010 09:50 AM, David Miller wrote:
> From: Eric Dumazet<eric.dumazet@gmail.com>
> Date: Thu, 18 Nov 2010 18:48:17 +0100
>
>> Let me guess...
>>
>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>> statically (in vmlinux) ?
>>
>> CONFIG_NF_CONNTRACK=m
>> CONFIG_IP_VS=y
>>
>> We probably need some Kconfig magic ;)
>
> Randy Dunlap made a similar report today with a sample .config
> that triggers the problem.
>
> I'll look into it after lunch.
>
alright..
Justin P. Mattock
^ permalink raw reply
* [PATCH 4/4] net: caif: spi: fix potential NULL dereference
From: Vasiliy Kulikov @ 2010-11-18 18:17 UTC (permalink / raw)
To: kernel-janitors; +Cc: Sjur Braendeland, netdev, linux-kernel
alloc_netdev() is not checked here for NULL return value. dev is
check instead. It might lead to NULL dereference of ndev.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
Maybe dev is also must be checked here, but it looks like a trivial typo.
drivers/net/caif/caif_spi.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index 8b4cea5..20da199 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -635,8 +635,8 @@ int cfspi_spi_probe(struct platform_device *pdev)
ndev = alloc_netdev(sizeof(struct cfspi),
"cfspi%d", cfspi_setup);
- if (!dev)
- return -ENODEV;
+ if (!ndev)
+ return -ENOMEM;
cfspi = netdev_priv(ndev);
netif_stop_queue(ndev);
--
1.7.0.4
^ permalink raw reply related
* Re: error while building the kernel Mainline
From: Patrick McHardy @ 2010-11-18 18:20 UTC (permalink / raw)
To: Justin P. Mattock
Cc: David Miller, eric.dumazet, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <4CE56CC4.4020107@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
Am 18.11.2010 19:13, schrieb Justin P. Mattock:
> On 11/18/2010 09:50 AM, David Miller wrote:
>> From: Eric Dumazet<eric.dumazet@gmail.com>
>> Date: Thu, 18 Nov 2010 18:48:17 +0100
>>
>>> Let me guess...
>>>
>>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>>> statically (in vmlinux) ?
>>>
>>> CONFIG_NF_CONNTRACK=m
>>> CONFIG_IP_VS=y
>>>
>>> We probably need some Kconfig magic ;)
>>
Please try whether this patch fixes the problem.
netfilter: fix IP_VS dependencies
When NF_CONNTRACK is enabled, IP_VS uses conntrack symbols.
Therefore IP_VS can't be linked statically when conntrack
is built modular.
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 473 bytes --]
diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
index a22dac2..70bd1d0 100644
--- a/net/netfilter/ipvs/Kconfig
+++ b/net/netfilter/ipvs/Kconfig
@@ -4,6 +4,7 @@
menuconfig IP_VS
tristate "IP virtual server support"
depends on NET && INET && NETFILTER
+ depends on (NF_CONNTRACK || NF_CONNTRACK=n)
---help---
IP Virtual Server support will let you build a high-performance
virtual server based on cluster of two or more real servers. This
^ permalink raw reply related
* Re: error while building the kernel Mainline
From: Justin P. Mattock @ 2010-11-18 18:28 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, eric.dumazet, linux-net, linux-kernel, netdev,
horms, netfilter-devel
In-Reply-To: <4CE56E89.4000902@trash.net>
On 11/18/2010 10:20 AM, Patrick McHardy wrote:
> Am 18.11.2010 19:13, schrieb Justin P. Mattock:
>> On 11/18/2010 09:50 AM, David Miller wrote:
>>> From: Eric Dumazet<eric.dumazet@gmail.com>
>>> Date: Thu, 18 Nov 2010 18:48:17 +0100
>>>
>>>> Let me guess...
>>>>
>>>> net/netfilter/nf_conntrack_core is compiled as a module, and ip_vs
>>>> statically (in vmlinux) ?
>>>>
>>>> CONFIG_NF_CONNTRACK=m
>>>> CONFIG_IP_VS=y
>>>>
>>>> We probably need some Kconfig magic ;)
>>>
>
> Please try whether this patch fixes the problem.
sure.. right now I'm rebuilding with conntract built-in as suggested by
eric. then ill go back and test your patch out
>
> netfilter: fix IP_VS dependencies
>
> When NF_CONNTRACK is enabled, IP_VS uses conntrack symbols.
> Therefore IP_VS can't be linked statically when conntrack
> is built modular.
>
> Reported-by: Justin P. Mattock<justinmattock@gmail.com>
> Signed-off-by: Patrick McHardy<kaber@trash.net>
>
>
Justin P. Mattock
^ permalink raw reply
* Re: linux-next: Tree for November 18 (netfilter)
From: Patrick McHardy @ 2010-11-18 18:32 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, netfilter-devel, linux-next, LKML, netdev,
KOVACS Krisztian, Balazs Scheidler
In-Reply-To: <20101118092520.6ad964c7.randy.dunlap@oracle.com>
Am 18.11.2010 18:25, schrieb Randy Dunlap:
> On Thu, 18 Nov 2010 13:42:56 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101117:
>
>
> include/net/netfilter/nf_conntrack.h:94: error: field 'ct_general' has incomplete type
> include/net/netfilter/nf_conntrack.h:174: error: 'const struct sk_buff' has no member named 'nfct'
> include/net/netfilter/nf_conntrack.h:181: error: implicit declaration of function 'nf_conntrack_put'
> include/net/netfilter/nf_conntrack_ecache.h:35: error: 'struct net' has no member named 'ct'
> include/net/netfilter/nf_conntrack_core.h:60: error: 'struct sk_buff' has no member named 'nfct'
> net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:36: error: 'struct sk_buff' has no member named 'nfct'
> net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: implicit declaration of function 'nf_ct_zone'
> net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: 'struct sk_buff' has no member named 'nfct'
> net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> net/ipv6/netfilter/nf_conntrack_reasm.c:598: error: implicit declaration of function 'nf_conntrack_put_reasm'
> net/ipv6/netfilter/nf_conntrack_reasm.c:598: error: 'struct sk_buff' has no member named 'nfct_reasm'
> net/ipv6/netfilter/nf_conntrack_reasm.c:599: error: implicit declaration of function 'nf_conntrack_get_reasm'
> net/ipv6/netfilter/nf_conntrack_reasm.c:600: error: 'struct sk_buff' has no member named 'nfct_reasm'
>
>
> randconfig file is attached.
Krisztian, Balazs, could you please have a look at this? If the
intention is to use NF_DEFRAG_IPV6 without conntrack, we probably
need a couple of ifdefs.
^ permalink raw reply
* Re: extended netdevice naming proposal
From: Rick Jones @ 2010-11-18 18:34 UTC (permalink / raw)
To: Matt Domsch; +Cc: linux-hotplug, netdev, narendra_k, jcm, notting
In-Reply-To: <20101117220659.GA12177@auslistsprd01.us.dell.com>
With the presence of the pci_slot driver to allow association of the PCI address
with a "slot name" is encoding such information into the interface name really
necessary?
rick jones
^ permalink raw reply
* Re: [PATCH 4/4] net: caif: spi: fix potential NULL dereference
From: David Miller @ 2010-11-18 18:36 UTC (permalink / raw)
To: segoon; +Cc: kernel-janitors, sjur.brandeland, netdev, linux-kernel
In-Reply-To: <1290104226-31428-1-git-send-email-segoon@openwall.com>
From: Vasiliy Kulikov <segoon@openwall.com>
Date: Thu, 18 Nov 2010 21:17:05 +0300
> alloc_netdev() is not checked here for NULL return value. dev is
> check instead. It might lead to NULL dereference of ndev.
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
> ---
> Compile tested.
> Maybe dev is also must be checked here, but it looks like a trivial typo.
Definitely looks correct to me, applied, thanks!
^ permalink raw reply
* pull request: wireless-2.6 2010-11-18
From: John W. Linville @ 2010-11-18 18:41 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
This is a batch of wireless fixes intended for 2.6.37.
Included is an build fix for b43legacy on ARM, a correction of a
misnumbered WIPHY_FLAG_* value, a fix for the units passed to
usb_wait_anchor_empty_timeout in carl9170, a relocation of ath9k's
pm_qos request to avoid a warning about an unknown object, some device
ID stuff for ath9k_htc, a corrected eeprom offset for AR9287 devices, a
regulatory fix for extension channels, a fix on top of the regulatory
fix that restores HT40 functionality, and an ath9k_htc fix for non-QoS
frame handling that avoids "severe data loss with some APs".
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 28cb6ccd2c7e86b3a4db94c7062cd27937bed424:
gianfar: fix signedness issue (2010-11-17 12:39:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Arnd Hannemann (1):
b43legacy: Fix compile on ARM architecture
Christian Lamparter (1):
carl9170: fix usb anchor wait timeout
Jussi Kivilinna (1):
cfg80211: fix WIPHY_FLAG_IBSS_RSN bit
Luis R. Rodriguez (1):
cfg80211: fix extension channel checks to initiate communication
Mark Mentovai (1):
cfg80211: fix can_beacon_sec_chan, reenable HT40
Rajkumar Manoharan (4):
ath9k_htc: Update usb device ID list
ath9k_htc: Add new devices into AR7010
ath9k_hw: Set proper eeprom offset for AR9287 HTC devices
ath9k_htc: Avoid setting QoS control for non-QoS frames
Vivek Natarajan (1):
ath9k: Remove pm_qos request after hw unregister.
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 ++++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 3 +-
drivers/net/wireless/ath/ath9k/reg.h | 8 +++-
drivers/net/wireless/ath/carl9170/usb.c | 4 +-
include/net/cfg80211.h | 2 +-
include/net/dst_ops.h | 1 +
net/wireless/chan.c | 54 +++++++++++++++++++++++++
10 files changed, 79 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index 966b949..195406d 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -37,7 +37,7 @@ static bool ath9k_hw_ar9287_fill_eeprom(struct ath_hw *ah)
int addr, eep_start_loc;
eep_data = (u16 *)eep;
- if (ah->hw_version.devid == 0x7015)
+ if (AR9287_HTC_DEVID(ah))
eep_start_loc = AR9287_HTC_EEP_START_LOC;
else
eep_start_loc = AR9287_EEP_START_LOC;
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f7ec31b..dfb6560 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -36,8 +36,13 @@ static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x13D3, 0x3327) }, /* Azurewave */
{ USB_DEVICE(0x13D3, 0x3328) }, /* Azurewave */
{ USB_DEVICE(0x13D3, 0x3346) }, /* IMC Networks */
+ { USB_DEVICE(0x13D3, 0x3348) }, /* Azurewave */
+ { USB_DEVICE(0x13D3, 0x3349) }, /* Azurewave */
+ { USB_DEVICE(0x13D3, 0x3350) }, /* Azurewave */
{ USB_DEVICE(0x04CA, 0x4605) }, /* Liteon */
{ USB_DEVICE(0x083A, 0xA704) }, /* SMC Networks */
+ { USB_DEVICE(0x040D, 0x3801) }, /* VIA */
+ { USB_DEVICE(0x1668, 0x1200) }, /* Verizon */
{ },
};
@@ -806,6 +811,8 @@ static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
case 0x7010:
case 0x7015:
case 0x9018:
+ case 0xA704:
+ case 0x1200:
firm_offset = AR7010_FIRMWARE_TEXT;
break;
default:
@@ -928,6 +935,8 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
case 0x7010:
case 0x7015:
case 0x9018:
+ case 0xA704:
+ case 0x1200:
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x0202)
hif_dev->fw_name = FIRMWARE_AR7010_1_1;
else
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 3d7b97f..7c8a38d 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -249,6 +249,8 @@ static int ath9k_init_htc_services(struct ath9k_htc_priv *priv, u16 devid)
case 0x7010:
case 0x7015:
case 0x9018:
+ case 0xA704:
+ case 0x1200:
priv->htc->credits = 45;
break;
default:
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 3d19b5b..29d80ca 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -121,7 +121,7 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
tx_hdr.data_type = ATH9K_HTC_NORMAL;
}
- if (ieee80211_is_data(fc)) {
+ if (ieee80211_is_data_qos(fc)) {
qc = ieee80211_get_qos_ctl(hdr);
tx_hdr.tidno = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
}
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 6a0d99e..92bc5c5 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -817,8 +817,6 @@ void ath9k_deinit_device(struct ath_softc *sc)
ath9k_ps_wakeup(sc);
- pm_qos_remove_request(&ath9k_pm_qos_req);
-
wiphy_rfkill_stop_polling(sc->hw->wiphy);
ath_deinit_leds(sc);
@@ -832,6 +830,7 @@ void ath9k_deinit_device(struct ath_softc *sc)
}
ieee80211_unregister_hw(hw);
+ pm_qos_remove_request(&ath9k_pm_qos_req);
ath_rx_cleanup(sc);
ath_tx_cleanup(sc);
ath9k_deinit_softc(sc);
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index fa05b71..dddf579 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -866,7 +866,13 @@
#define AR_DEVID_7010(_ah) \
(((_ah)->hw_version.devid == 0x7010) || \
((_ah)->hw_version.devid == 0x7015) || \
- ((_ah)->hw_version.devid == 0x9018))
+ ((_ah)->hw_version.devid == 0x9018) || \
+ ((_ah)->hw_version.devid == 0xA704) || \
+ ((_ah)->hw_version.devid == 0x1200))
+
+#define AR9287_HTC_DEVID(_ah) \
+ (((_ah)->hw_version.devid == 0x7015) || \
+ ((_ah)->hw_version.devid == 0x1200))
#define AR_RADIO_SREV_MAJOR 0xf0
#define AR_RAD5133_SREV_MAJOR 0xc0
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index 3317039..7504ed1 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -553,12 +553,12 @@ static int carl9170_usb_flush(struct ar9170 *ar)
usb_free_urb(urb);
}
- ret = usb_wait_anchor_empty_timeout(&ar->tx_cmd, HZ);
+ ret = usb_wait_anchor_empty_timeout(&ar->tx_cmd, 1000);
if (ret == 0)
err = -ETIMEDOUT;
/* lets wait a while until the tx - queues are dried out */
- ret = usb_wait_anchor_empty_timeout(&ar->tx_anch, HZ);
+ ret = usb_wait_anchor_empty_timeout(&ar->tx_anch, 1000);
if (ret == 0)
err = -ETIMEDOUT;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 2a7936d..97b8b7c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1355,7 +1355,7 @@ enum wiphy_flags {
WIPHY_FLAG_4ADDR_AP = BIT(5),
WIPHY_FLAG_4ADDR_STATION = BIT(6),
WIPHY_FLAG_CONTROL_PORT_PROTOCOL = BIT(7),
- WIPHY_FLAG_IBSS_RSN = BIT(7),
+ WIPHY_FLAG_IBSS_RSN = BIT(8),
};
struct mac_address {
diff --git a/include/net/dst_ops.h b/include/net/dst_ops.h
index 1fa5306..51665b3 100644
--- a/include/net/dst_ops.h
+++ b/include/net/dst_ops.h
@@ -2,6 +2,7 @@
#define _NET_DST_OPS_H
#include <linux/types.h>
#include <linux/percpu_counter.h>
+#include <linux/cache.h>
struct dst_entry;
struct kmem_cachep;
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index d0c92dd..17cd0c0 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -44,6 +44,38 @@ rdev_freq_to_chan(struct cfg80211_registered_device *rdev,
return chan;
}
+static bool can_beacon_sec_chan(struct wiphy *wiphy,
+ struct ieee80211_channel *chan,
+ enum nl80211_channel_type channel_type)
+{
+ struct ieee80211_channel *sec_chan;
+ int diff;
+
+ switch (channel_type) {
+ case NL80211_CHAN_HT40PLUS:
+ diff = 20;
+ break;
+ case NL80211_CHAN_HT40MINUS:
+ diff = -20;
+ break;
+ default:
+ return false;
+ }
+
+ sec_chan = ieee80211_get_channel(wiphy, chan->center_freq + diff);
+ if (!sec_chan)
+ return false;
+
+ /* we'll need a DFS capability later */
+ if (sec_chan->flags & (IEEE80211_CHAN_DISABLED |
+ IEEE80211_CHAN_PASSIVE_SCAN |
+ IEEE80211_CHAN_NO_IBSS |
+ IEEE80211_CHAN_RADAR))
+ return false;
+
+ return true;
+}
+
int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev, int freq,
enum nl80211_channel_type channel_type)
@@ -68,6 +100,28 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
if (!chan)
return -EINVAL;
+ /* Both channels should be able to initiate communication */
+ if (wdev && (wdev->iftype == NL80211_IFTYPE_ADHOC ||
+ wdev->iftype == NL80211_IFTYPE_AP ||
+ wdev->iftype == NL80211_IFTYPE_AP_VLAN ||
+ wdev->iftype == NL80211_IFTYPE_MESH_POINT ||
+ wdev->iftype == NL80211_IFTYPE_P2P_GO)) {
+ switch (channel_type) {
+ case NL80211_CHAN_HT40PLUS:
+ case NL80211_CHAN_HT40MINUS:
+ if (!can_beacon_sec_chan(&rdev->wiphy, chan,
+ channel_type)) {
+ printk(KERN_DEBUG
+ "cfg80211: Secondary channel not "
+ "allowed to initiate communication\n");
+ return -EINVAL;
+ }
+ break;
+ default:
+ break;
+ }
+ }
+
result = rdev->ops->set_channel(&rdev->wiphy,
wdev ? wdev->netdev : NULL,
chan, channel_type);
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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 related
* Re: [net-next-2.6 PATCH] net: add priority field to pktgen
From: David Miller @ 2010-11-18 18:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: john.r.fastabend, netdev
In-Reply-To: <1289971637.2732.83.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 17 Nov 2010 06:27:17 +0100
> Le mardi 16 novembre 2010 à 21:12 -0800, John Fastabend a écrit :
>> Add option to set skb priority to pktgen. Useful for testing
>> QOS features. Also by running pktgen on the vlan device the
>> qdisc on the real device can be tested.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
This will be useful for stressing things like VLAN qos I guess
:-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox