* [PATCH 0/6] netdev: octeon_mgmt: A few fixes for 2.6.35.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
The 1/6 corrects a compile error that seems to have crept
in, as well as correcting the dev_addrs/uc snafu.
2/6 - 5/6 are some other small bug fixes.
6/6 just re-formats the code some.
They are relative to commit 0a12761bcd5646691c5d16dd93df84d1b8849285
in net-next-2.6/master
If OK please apply.
Thanks,
David Daney
David Daney (6):
netdev: octeon_mgmt: Use proper MAC addresses.
netdev: octeon_mgmt: Fix race condition freeing TX buffers.
netdev: octeon_mgmt: Fix race manipulating irq bits.
netdev: octeon_mgmt: Free TX skbufs in a timely manner.
netdev: octeon_mgmt: Try not to drop TX packets when stopping the
queue.
netdev: octeon_mgmt: Remove some gratuitous blank lines.
drivers/net/octeon/octeon_mgmt.c | 57 ++++++++++++++++++-------------------
1 files changed, 28 insertions(+), 29 deletions(-)
^ permalink raw reply
* [PATCH 1/6] netdev: octeon_mgmt: Use proper MAC addresses.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
The original implementation incorrectly uses netdev->dev_addrs.
Use netdev->uc instead. Also use netdev_for_each_uc_addr to iterate
over the addresses. Fix comment.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index 6b1d443..bbbd737 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -475,12 +475,11 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
unsigned int multicast_mode = 1; /* 1 - Reject all multicast. */
struct octeon_mgmt_cam_state cam_state;
struct netdev_hw_addr *ha;
- struct list_head *pos;
int available_cam_entries;
memset(&cam_state, 0, sizeof(cam_state));
- if ((netdev->flags & IFF_PROMISC) || netdev->dev_addrs.count > 7) {
+ if ((netdev->flags & IFF_PROMISC) || netdev->uc.count > 7) {
cam_mode = 0;
available_cam_entries = 8;
} else {
@@ -488,13 +487,13 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
* One CAM entry for the primary address, leaves seven
* for the secondary addresses.
*/
- available_cam_entries = 7 - netdev->dev_addrs.count;
+ available_cam_entries = 7 - netdev->uc.count;
}
if (netdev->flags & IFF_MULTICAST) {
if (cam_mode == 0 || (netdev->flags & IFF_ALLMULTI) ||
netdev_mc_count(netdev) > available_cam_entries)
- multicast_mode = 2; /* 1 - Accept all multicast. */
+ multicast_mode = 2; /* 2 - Accept all multicast. */
else
multicast_mode = 0; /* 0 - Use CAM. */
}
@@ -502,12 +501,8 @@ static void octeon_mgmt_set_rx_filtering(struct net_device *netdev)
if (cam_mode == 1) {
/* Add primary address. */
octeon_mgmt_cam_state_add(&cam_state, netdev->dev_addr);
- list_for_each(pos, &netdev->dev_addrs.list) {
- struct netdev_hw_addr *hw_addr;
- hw_addr = list_entry(pos, struct netdev_hw_addr, list);
- octeon_mgmt_cam_state_add(&cam_state, hw_addr->addr);
- list = list->next;
- }
+ netdev_for_each_uc_addr(ha, netdev)
+ octeon_mgmt_cam_state_add(&cam_state, ha->addr);
}
if (multicast_mode == 0) {
netdev_for_each_mc_addr(ha, netdev)
--
1.6.6.1
^ permalink raw reply related
* [PATCH 2/6] netdev: octeon_mgmt: Fix race condition freeing TX buffers.
From: David Daney @ 2010-05-05 23:03 UTC (permalink / raw)
To: netdev; +Cc: linux-mips, David Daney
In-Reply-To: <1273100593-11043-1-git-send-email-ddaney@caviumnetworks.com>
Under heavy load the TX cleanup tasklet and xmit threads would race
and try to free too many buffers.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
---
drivers/net/octeon/octeon_mgmt.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/octeon/octeon_mgmt.c b/drivers/net/octeon/octeon_mgmt.c
index bbbd737..b975a2f 100644
--- a/drivers/net/octeon/octeon_mgmt.c
+++ b/drivers/net/octeon/octeon_mgmt.c
@@ -189,12 +189,19 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt *p)
mix_orcnt.u64 = cvmx_read_csr(CVMX_MIXX_ORCNT(port));
while (mix_orcnt.s.orcnt) {
+ spin_lock_irqsave(&p->tx_list.lock, flags);
+
+ mix_orcnt.u64 = cvmx_read_csr(CVMX_MIXX_ORCNT(port));
+
+ if (mix_orcnt.s.orcnt == 0) {
+ spin_unlock_irqrestore(&p->tx_list.lock, flags);
+ break;
+ }
+
dma_sync_single_for_cpu(p->dev, p->tx_ring_handle,
ring_size_to_bytes(OCTEON_MGMT_TX_RING_SIZE),
DMA_BIDIRECTIONAL);
- spin_lock_irqsave(&p->tx_list.lock, flags);
-
re.d64 = p->tx_ring[p->tx_next_clean];
p->tx_next_clean =
(p->tx_next_clean + 1) % OCTEON_MGMT_TX_RING_SIZE;
--
1.6.6.1
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2010-05-05
From: David Miller @ 2010-05-05 22:40 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100505203528.GB2603@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 5 May 2010 16:35:29 -0400
> Dave,
>
> Another enormous batch intended for 2.6.35... This is mostly the 'usual
> suspects' -- driver updates from Intel, Atheros, Nokia, and the rt2x00
> guys, mac80211 stuff from Johannes, and a variety of other bits. One
> noteworth bit is the addition of the orinoco_usb driver.
Pulled, thanks John.
^ permalink raw reply
* RE: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Shreyas Bhatewara @ 2010-05-05 22:05 UTC (permalink / raw)
To: Arnd Bergmann, Dmitry Torokhov
Cc: Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, Pankaj Thakkar
In-Reply-To: <201005052353.16544.arnd@arndb.de>
> -----Original Message-----
> From: pv-drivers-bounces@vmware.com [mailto:pv-drivers-
> bounces@vmware.com] On Behalf Of Arnd Bergmann
> Sent: Wednesday, May 05, 2010 2:53 PM
> To: Dmitry Torokhov
> Cc: Christoph Hellwig; pv-drivers@vmware.com; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; virtualization@lists.linux-
> foundation.org; Pankaj Thakkar
> Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
> vmxnet3
>
> On Wednesday 05 May 2010 22:36:31 Dmitry Torokhov wrote:
> >
> > On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote:
> > > > > If you have any interesting in developing this further, do:
> > > > >
> > > > > (1) move the limited VF drivers directly into the kernel tree,
> > > > > talk to them through a normal ops vector
> > > >
> > > > [PT] This assumes that all the VF drivers would always be
> available.
> > > > Also we have to support windows and our current design supports
> it
> > > > nicely in an OS agnostic manner.
> > >
> > > Your approach assumes that the plugin is always available, which
> has
> > > exactly the same implications.
> >
> > Since plugin[s] are carried by the host they are indeed always
> > available.
>
> But what makes you think that you can build code that can be linked
> into arbitrary future kernel versions? The kernel does not define any
> calling conventions that are stable across multiple versions or
> configurations. For example, you'd have to provide different binaries
> for each combination of
The plugin image is not linked against Linux kernel. It is OS agnostic infact (Eg. same plugin works for Linux and Windows VMs)
Plugin is built against the shell API interface. It is loaded by hypervisor in a set of pages provided by shell. Guest OS specific tasks (like allocation of pages for plugin to load) are handled by shell and this is the one which will be upstreamed in Linux kernel. Maintenance of shell is the same as for any other driver currently existing in Linux kernel.
->Shreyas
>
> - 32/64 bit code
> - gcc -mregparm=?
> - lockdep
> - tracepoints
> - stackcheck
> - NOMMU
> - highmem
> - whatever new gets merged
>
> If you build the plugins only for specific versions of "enterprise"
> Linux
> kernels, the code becomes really hard to debug and maintain.
> If you wrap everything in your own version of the existing interfaces,
> your
> code gets bloated to the point of being unmaintainable.
>
> So I have to correct myself: this is very different from assuming the
> driver is available in the guest, it's actually much worse.
>
> Arnd
> _______________________________________________
> Pv-drivers mailing list
> Pv-drivers@vmware.com
> http://mailman2.vmware.com/mailman/listinfo/pv-drivers
^ permalink raw reply
* Re: 3 packet TCP window limit?
From: Stephen Hemminger @ 2010-05-05 22:03 UTC (permalink / raw)
To: Brian Bloniarz; +Cc: dormando, netdev, Rick Jones, shemminger
In-Reply-To: <4BE1DB82.2030403@athenacr.com>
On Wed, 05 May 2010 16:56:34 -0400
Brian Bloniarz <bmb@athenacr.com> wrote:
> dormando wrote:
> >> This sounds like TCP slow start.
> >>
> >> http://en.wikipedia.org/wiki/Slow-start
> >>
> >> As far as tunables you might want to play with the initcwnd route
> >> flag (see "ip route help")
> >
> > Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
> > start / etc. However I couldn't find the damn tunable for it :)
>
> Documenting the flag in ip(8) might increase its visibility
> a little. I don't see it documented in the iproute2 git head,
> though it shows up on http://linux.die.net/man/8/ip somehow.
>
> Stephen, do you know why that is?
No one sent me an official patch to change it?
^ permalink raw reply
* Re: [PATCH 2/6] netns: Teach network device kobjects which namespace they are in.
From: Serge E. Hallyn @ 2010-05-05 22:01 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Greg Kroah-Hartman, Kay Sievers, linux-kernel, Tejun Heo,
Cornelia Huck, Eric Dumazet, Benjamin LaHaise, netdev,
David Miller
In-Reply-To: <m14oim2kcm.fsf@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > Quoting Eric W. Biederman (ebiederm@xmission.com):
> >> diff --git a/net/Kconfig b/net/Kconfig
> >> index 041c35e..265e33b 100644
> >> --- a/net/Kconfig
> >> +++ b/net/Kconfig
> >> @@ -45,6 +45,14 @@ config COMPAT_NETLINK_MESSAGES
> >>
> >> menu "Networking options"
> >>
> >> +config NET_NS
> >> + bool "Network namespace support"
> >> + default n
> >> + depends on EXPERIMENTAL && NAMESPACES
> >> + help
> >> + Allow user space to create what appear to be multiple instances
> >> + of the network stack.
> >> +
> >
> > Hi Eric,
> >
> > I'm confused - NET_NS is defined in init/Kconfig right now. Is the tree
> > you're working from very different from mine, or is this the unfortunate
> > rekult of the patches sitting so long?
>
> Old patches, nothing that complains when you make a mistake like this,
> and apparently I have a blind spot in my personal code review.
haha, we all know about that.
> At one point it was not possible to enable the network namespace until
> the sysfs stuff was enabled, but things have been going on long enough
> that we worked around that restriction.
Yeah, I remember that, and leaving this wouldn't break anything.
> >> int netdev_kobject_init(void)
> >> {
> >> + kobj_ns_type_register(&net_ns_type_operations);
> >> +#ifdef CONFIG_SYSFS
> >> + register_pernet_subsys(&sysfs_net_ops);
> >> +#endif
> >> return class_register(&net_class);
> >
> > I think the kobj_ns_type_register() needs to be under
> > ifdef CONFIG_SYSFS as well, bc net_ns_type_operations is defined
> > under ifdef CONFIG_SYSFS.
>
> kobj_ns_type_register should not be under CONFIG_SYSFS. Which means
> that kobj_ns_type_operations needs not to be under CONFIG_SYSFS as
> well. That you for spotting that bug.
np - outside of that,
Acked-by: Serge E. Hallyn <serue@us.ibm.com>
I saw no problems with the other patches, just don't feel qualified
to give an ack.
thanks,
-serge
^ permalink raw reply
* Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?
From: David Miller @ 2010-05-05 22:00 UTC (permalink / raw)
To: brian.haley; +Cc: dlstevens, enh, netdev, netdev-owner
In-Reply-To: <4BE1907F.40903@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Wed, 05 May 2010 11:36:31 -0400
> I now see that in Elliot's email, but I think it's incorrect. The RFC
> says that setting it to -1 should get you the kernel default, which is
> now 1. Without this change, setting it to -1 will get you 64, the
> old behavior. If the user wants to, they can always just set it to
> 64 themselves, that's better than assuming when you set it to -1
> you're going to get 64.
It's not 64, it's whatever the per-route metric is.
> I'm just trying to make this follow the RFC and behave like other OSes
> for consistency.
I'm just trying to have a real compatability story, and we don't with
any of the proposals you guys are giving me because it complete ignores
the fact that the old default comes from the route and is not some
constant.
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Arnd Bergmann @ 2010-05-05 21:53 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: virtualization@lists.linux-foundation.org, Pankaj Thakkar,
Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <201005051336.32712.dtor@vmware.com>
On Wednesday 05 May 2010 22:36:31 Dmitry Torokhov wrote:
>
> On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote:
> > > > If you have any interesting in developing this further, do:
> > > >
> > > > (1) move the limited VF drivers directly into the kernel tree,
> > > > talk to them through a normal ops vector
> > >
> > > [PT] This assumes that all the VF drivers would always be available.
> > > Also we have to support windows and our current design supports it
> > > nicely in an OS agnostic manner.
> >
> > Your approach assumes that the plugin is always available, which has
> > exactly the same implications.
>
> Since plugin[s] are carried by the host they are indeed always
> available.
But what makes you think that you can build code that can be linked
into arbitrary future kernel versions? The kernel does not define any
calling conventions that are stable across multiple versions or
configurations. For example, you'd have to provide different binaries
for each combination of
- 32/64 bit code
- gcc -mregparm=?
- lockdep
- tracepoints
- stackcheck
- NOMMU
- highmem
- whatever new gets merged
If you build the plugins only for specific versions of "enterprise" Linux
kernels, the code becomes really hard to debug and maintain.
If you wrap everything in your own version of the existing interfaces, your
code gets bloated to the point of being unmaintainable.
So I have to correct myself: this is very different from assuming the
driver is available in the guest, it's actually much worse.
Arnd
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: __alloc_skb() speedup
From: David Miller @ 2010-05-05 21:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hadi, therbert
In-Reply-To: <1273060809.2367.67.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 05 May 2010 14:00:09 +0200
> Sorry, I was thinking about the shinfo part :
>
> memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
>
> offsetof(struct skb_shared_info, dataref) is small enough and we dont
> dirty a full cache line, so maybe I can keep prefetchw(data + size) ?
You do dirty a full line on sparc64, the prefetch invalidate goes a L1
cache line at a time, so 32 bytes. And this memset() is 40 bytes.
The call to the memset symbol is still generated by gcc for this case.
I think the cutoff for doing it inline is something like 16 bytes on
sparc64, four 64-bit loads and stores.
Unlike x86 these risc chips don't have string-op instructions, and for
sparc64 and powerpc the instructions are fixed in size (4 bytes) so
the inline cost is "(memset_size / word_size) * 4". Whereas on x86 the
inlining cost is more-or-less fixed.
> If not, in which cases can we use prefetchw() in kernel, if some arches
> dont handle it well ?
It has to be looked at in a case-by-case basis. There is no simple
answer here.
^ permalink raw reply
* Re: [PATCH/RFC] cxgb4: Add MAINTAINERS info
From: Divy Le Ray @ 2010-05-05 21:40 UTC (permalink / raw)
To: Steve Wise
Cc: Roland Dreier, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, dm-ut6Up61K2wZBDgjK7y7TUQ
In-Reply-To: <4BE1CE39.1050707-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
On 05/05/2010 12:59 PM, Steve Wise wrote:
> Looks good to me.
It looks right to me too.
Cheers,
Divy
>
> Steve.
>
> Roland Dreier wrote:
>> Hi guys, does this info for cxgb4/iw_cxgb4 (pretty much copied from
>> cxgb3, except with Dimitris instead of Divy) look right? If so I'll add
>> it to my tree.
>>
>> Thanks,
>> Roland
>> ---
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7a9ccda..a00231b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -1719,6 +1719,20 @@ W: http://www.openfabrics.org
>> S: Supported
>> F: drivers/infiniband/hw/cxgb3/
>>
>> +CXGB4 ETHERNET DRIVER (CXGB4)
>> +M: Dimitris Michailidis <dm-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>> +L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> +W: http://www.chelsio.com
>> +S: Supported
>> +F: drivers/net/cxgb4/
>> +
>> +CXGB4 IWARP RNIC DRIVER (IW_CXGB4)
>> +M: Steve Wise <swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>> +L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> +W: http://www.openfabrics.org
>> +S: Supported
>> +F: drivers/infiniband/hw/cxgb4/
>> +
>> CYBERPRO FB DRIVER
>> M: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>> L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for
>> non-subscribers)
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: 3 packet TCP window limit?
From: dormando @ 2010-05-05 21:31 UTC (permalink / raw)
To: Rick Jones; +Cc: Brian Bloniarz, netdev
In-Reply-To: <4BE1D3B0.9000207@hp.com>
> I don't believe linux as yet has a damn tunable for it :)
ip route initcwnd sure does it :)
> > Other OS's appear to have a larger initcwnd.
>
> Names? Values?
OpenBSD 4.6 jumps between a ~5k fetch to a ~6k fetch
> > As do commercial load balancers.
>
> Names? Values?
An older Big/IP appears to be between 5k and 6k as well. I remember a
sales meeting with netscaler (pre-NDA) back in 2004 or 2005 where they
claimed to have opened up slow start. There might be others but I can't
remember which side of the NDA I was informed of their TCP tunning.
Linux is consistently between 3k and 4k. Just the distinction from having
the RTT in the ~4k or the ~6k range makes our latency graphs go nutty.
I've been testing a subset of traffic at an initcwnd of 10 for the last
few hours and latency has dropped even more, though I see some bad
outliers.
> > The default of 3 seems to be tuned for 56k dialup modems. I'm a
> > little surprised that none of the pluggable TCP congestion control
> > algorithms changed this value. I went through all of them except for
> > tcp_yeah.
>
> The initcwnd comes from IETF RFCs and their "thou shalts" and "thou shalt
> nots." As you note below, Google et al seek to alter/extend the RFCs. That
> is an ongoing discussion in some of the ietf related mailing lists.
The RFC clearly states "around 4k", but these other OS's/products have an
extra kilobyte snuck in? Could this be on purpose via rfc
interpretation, or an off by one on the initcwnd estimator? :)
^ permalink raw reply
* Re: 3 packet TCP window limit?
From: Brian Bloniarz @ 2010-05-05 20:56 UTC (permalink / raw)
To: dormando; +Cc: netdev, Rick Jones, shemminger
In-Reply-To: <alpine.LNX.2.00.1005051239290.28957@d>
dormando wrote:
>> This sounds like TCP slow start.
>>
>> http://en.wikipedia.org/wiki/Slow-start
>>
>> As far as tunables you might want to play with the initcwnd route
>> flag (see "ip route help")
>
> Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
> start / etc. However I couldn't find the damn tunable for it :)
Documenting the flag in ip(8) might increase its visibility
a little. I don't see it documented in the iproute2 git head,
though it shows up on http://linux.die.net/man/8/ip somehow.
Stephen, do you know why that is?
^ permalink raw reply
* [PATCH linux-next] irq: Clear CPU mask in affinity_hint when none is provided
From: Peter P Waskiewicz Jr @ 2010-05-05 20:56 UTC (permalink / raw)
To: tglx, davem, arjan, bhutchings; +Cc: netdev, linux-kernel
When an interrupt is disabled and torn down, the CPU mask
returned through affinity_hint right now is all CPUs. Also, for
drivers that don't provide an affinity_hint mask, this can be
misleading. There should be no hint at all, meaning an empty
CPU mask.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
kernel/irq/proc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index e1e7408..9ffa24d 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -45,7 +45,7 @@ static int irq_affinity_hint_proc_show(struct seq_file *m, void *v)
if (desc->affinity_hint)
cpumask_copy(mask, desc->affinity_hint);
else
- cpumask_setall(mask);
+ cpumask_clear(mask);
raw_spin_unlock_irqrestore(&desc->lock, flags);
seq_cpumask(m, mask);
^ permalink raw reply related
* pull request: wireless-next-2.6 2010-05-05
From: John W. Linville @ 2010-05-05 20:35 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
Another enormous batch intended for 2.6.35... This is mostly the 'usual
suspects' -- driver updates from Intel, Atheros, Nokia, and the rt2x00
guys, mac80211 stuff from Johannes, and a variety of other bits. One
noteworth bit is the addition of the orinoco_usb driver.
Please let me know if there are problems!
¡Olé!
Thanks,
John
---
The following changes since commit 0a12761bcd5646691c5d16dd93df84d1b8849285:
David S. Miller (1):
forcedeth: Kill NAPI config options.
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 for-davem
Abhijeet Kolekar (2):
iwlwifi: reset pci retry timeout
iwl3945: add ucode statistics
Benoit Papillault (1):
ath9k: Added get_survey callback in order to get channel noise
Dan Carpenter (1):
iwl: cleanup: remove unneeded error handling
Dan Williams (1):
libertas: fix 8686 firmware loading regression
Daniel Halperin (1):
iwlwifi: set AMPDU status variables correctly
David Kilroy (6):
orinoco: add hermes_ops
orinoco: allow driver to specify netdev_ops
orinoco: encapsulate driver locking
orinoco: add orinoco_usb driver
orinoco_usb: avoid in_atomic
orinoco_usb: implement fw download
Felix Fietkau (13):
mac80211: fix handling of 4-address-mode in ieee80211_change_iface
ath9k_hw: update initvals for AR9003
ath9k_hw: fix pll clock setting for 5ghz on AR9003
ath9k_hw: fix typo in the AR9003 EEPROM data structure definition
ath9k_hw: update EEPROM data structure for AR9280
ath9k_hw: fix fast clock handling for 5GHz channels
ath9k: wake queue after processing edma rx frames
ath9k_hw: use the configured power limit for AR9003
ath9k_hw: Fix typos in tx rate power level parsing for AR9003
ath9k_hw: Fix endian bug in an AR9003 EEPROM field
ath9k_hw: fix noisefloor timeout handling on AR9003
cfg80211: add ap isolation support
mac80211: implement ap isolation support
Gertjan van Wingerde (4):
rt2x00: Remove rt2x00pci.h include from rt2800lib.
rt2x00: Enable RT30xx by default.
rt2x00: Fix HT40+/HT40- setting in rt2800.
rt2x00: Register frame length in TX entry descriptor instead of L2PAD.
Hans de Goede (1):
p54pci: fix regression from prevent stuck rx-ring on slow system
Helmut Schaa (6):
rt2x00: rt2800lib: disable HT40 for now as it causes reception problems
rt2x00: rt2800: use tx_power2 in rt2800_config_channel_rf3xxx
rt2x00: fix typo in rt2800.h
rt2x00: rt2800lib: Fix rx path on SoC devices
rt2x00: rt2800lib: Remove redundant check for RT2872
rt2x00: rt2800lib: update rfcsr & bbp init code for SoC devices
Johannes Berg (9):
mac80211: give virtual interface to hw_scan
mac80211: notify driver about IBSS status
mac80211: tell driver about IBSS merge
iwlwifi: work around passive scan issue
mac80211: fix ieee80211_find_sta[_by_hw]
mac80211: allow controlling aggregation manually
mac80211: improve IBSS scanning
mac80211_hwsim: fix double-scan detection
mac80211: use fixed channel in ibss join when appropriate
John W. Linville (25):
ssb: do not read SPROM if it does not exist
MAINTAINERS: add entry for include/linux/iw_handler.h
mwl8k: remove usage of deprecated noise value
ar9170: remove usage of deprecated noise value
ath5k: remove usage of deprecated noise value
ath9k: remove usage of deprecated noise value
b43: remove usage of deprecated noise value
b43legacy: remove usage of deprecated noise value
libertas_tf: remove usage of deprecated noise value
p54: remove usage of deprecated noise value
rt2x00: remove usage of deprecated noise value
wl1251: remove usage of deprecated noise value
rtl8180: use cached queue mapping for skb in rtl8180_tx
rtl8180: fix tx status reporting
libertas_tf: avoid warning about pr_fmt redefinition
mac80211: remove deprecated noise field from ieee80211_rx_status
iwmc3200wifi: cleanup unneeded debugfs error handling
rt2x00: remove now unused noise field from struct rxdone_entry_desc
b43: Added get_survey callback in order to get channel noise
b43legacy: Added get_survey callback in order to get channel noise
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
iwmc3200wifi: fix busted iwm_debugfs_init definition
rtl8180: use SET_IEEE80211_PERM_ADDR
rtl8187: use SET_IEEE80211_PERM_ADDR
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Juuso Oikarinen (5):
mac80211: Fix sta->last_tx_rate setting with no-op rate control devices
mac80211: Determine dynamic PS timeout based on ps-qos network latency
cfg80211: Remove default dynamic PS timeout value
wl1271: Improve command polling
wl1271: Rewrite hardware keep-alive handling
Larry Finger (1):
ssb: Make bus registration failure not be silent
Luciano Coelho (1):
wl1271: fix a bunch of sparse warnings
Luis R. Rodriguez (2):
ath9k_hw: disable TX IQ calibration for AR9003
ath9k_hw: Fix TX interrupt mitigation settings
Rafał Miłecki (3):
ssb: Look for SPROM at different offset on higher rev CC
ssb: Use relative offsets for SPROM
ssb: Fix order of definitions and some text space indents
Reinette Chatre (2):
Merge branch 'wireless-2.6' into wireless-next-2.6
iwlwifi: recalculate average tpt if not current
Saravanan Dhanabal (1):
wl1271: Configure QOS nullfunc template for U-APSD
Shanyu Zhao (2):
mac80211: fix rts threshold check
iwlwifi: set correct AC to swq_id for aggregation
Stanislaw Gruszka (2):
mac80211: do not wip out old supported rates
mac80211: fix supported rates IE if AP doesn't give us it's rates
Steve deRosier (1):
libertastf: add configurable debug messages
Sujith (14):
ath9k_htc: Simplify TX URB management
ath9k_htc: Handle device unplug properly
ath9k_htc: Use multiple register writes
ath9k_htc: Cancel running timers before disabling HW
ath9k_hw: Remove pointless ANI deinit
ath9k_htc: Pass correct private pointer
ath9k_htc: Use USB reboot
ath9k_htc: Process command data properly
ath9k_htc: Increase WMI timeout value
ath9k_htc: Fix WMI command race
ath9k_htc: Really fix device hotunplug
ath9k_htc: Remove unnecessary powersave restore
ath9k_htc: Validate TX Endpoint ID
ath9k_htc: Simplify RX IRQ handler
Vasanthakumar Thiagarajan (1):
ath9k_hw: Fix usec to hw clock conversion in 5Ghz for ar9003
Vivek Natarajan (2):
ath9k_htc: Handle CONF_IDLE during unassociated state to save power.
ath9k: Avoid corrupt frames being forwarded to mac80211.
Wey-Yi Guy (4):
iwlwifi: remove get_stats callback function
iwlwifi: remove outdated comments
iwlwifi: set hw parameters based on device type
iwlwifi: greenfield support only true for 11n devices
Xose Vazquez Perez (1):
wireless: rt2x00: rt2800usb: be in sync with latest windows drivers.
MAINTAINERS | 1 +
drivers/net/wireless/Kconfig | 6 +
drivers/net/wireless/at76c50x-usb.c | 1 +
drivers/net/wireless/ath/ar9170/main.c | 4 +-
drivers/net/wireless/ath/ath5k/base.c | 6 +-
drivers/net/wireless/ath/ath9k/ani.c | 9 -
drivers/net/wireless/ath/ath9k/ani.h | 1 -
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 5 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 5 +
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 8 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 3 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_initvals.h | 265 ++--
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 3 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 16 +-
drivers/net/wireless/ath/ath9k/common.c | 1 -
drivers/net/wireless/ath/ath9k/eeprom.h | 3 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 149 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 1 -
drivers/net/wireless/ath/ath9k/htc.h | 2 +
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 8 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 84 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 59 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 5 +-
drivers/net/wireless/ath/ath9k/hw.c | 27 +-
drivers/net/wireless/ath/ath9k/hw.h | 8 +-
drivers/net/wireless/ath/ath9k/mac.c | 10 +-
drivers/net/wireless/ath/ath9k/main.c | 20 +
drivers/net/wireless/ath/ath9k/wmi.c | 11 +-
drivers/net/wireless/ath/ath9k/wmi.h | 4 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +
drivers/net/wireless/b43/main.c | 21 +-
drivers/net/wireless/b43/xmit.c | 1 -
drivers/net/wireless/b43legacy/main.c | 21 +-
drivers/net/wireless/b43legacy/xmit.c | 1 -
drivers/net/wireless/iwlwifi/Makefile | 1 +
drivers/net/wireless/iwlwifi/iwl-1000.c | 1 -
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c | 500 ++++++
drivers/net/wireless/iwlwifi/iwl-3945-debugfs.h | 60 +
drivers/net/wireless/iwlwifi/iwl-3945.c | 72 +-
drivers/net/wireless/iwlwifi/iwl-3945.h | 2 +
drivers/net/wireless/iwlwifi/iwl-5000.c | 73 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 73 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 23 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 14 -
drivers/net/wireless/iwlwifi/iwl-commands.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 5 +
drivers/net/wireless/iwlwifi/iwl-scan.c | 3 +-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 6 +-
drivers/net/wireless/iwmc3200wifi/bus.h | 2 +-
drivers/net/wireless/iwmc3200wifi/debug.h | 7 +-
drivers/net/wireless/iwmc3200wifi/debugfs.c | 110 +--
drivers/net/wireless/iwmc3200wifi/sdio.c | 17 +-
drivers/net/wireless/libertas/if_sdio.c | 4 +-
drivers/net/wireless/libertas_tf/cmd.c | 203 ++-
drivers/net/wireless/libertas_tf/deb_defs.h | 104 ++
drivers/net/wireless/libertas_tf/if_usb.c | 251 +++-
drivers/net/wireless/libertas_tf/libertas_tf.h | 2 +
drivers/net/wireless/libertas_tf/main.c | 91 +-
drivers/net/wireless/mac80211_hwsim.c | 6 +-
drivers/net/wireless/mwl8k.c | 6 +-
drivers/net/wireless/orinoco/Kconfig | 7 +
drivers/net/wireless/orinoco/Makefile | 1 +
drivers/net/wireless/orinoco/airport.c | 8 +-
drivers/net/wireless/orinoco/cfg.c | 2 +-
drivers/net/wireless/orinoco/fw.c | 10 +-
drivers/net/wireless/orinoco/hermes.c | 286 ++++-
drivers/net/wireless/orinoco/hermes.h | 62 +-
drivers/net/wireless/orinoco/hermes_dld.c | 243 +---
drivers/net/wireless/orinoco/hw.c | 63 +-
drivers/net/wireless/orinoco/main.c | 137 +-
drivers/net/wireless/orinoco/orinoco.h | 30 +-
drivers/net/wireless/orinoco/orinoco_cs.c | 6 +-
drivers/net/wireless/orinoco/orinoco_nortel.c | 2 +-
drivers/net/wireless/orinoco/orinoco_pci.c | 2 +-
drivers/net/wireless/orinoco/orinoco_plx.c | 2 +-
drivers/net/wireless/orinoco/orinoco_tmd.c | 2 +-
drivers/net/wireless/orinoco/orinoco_usb.c | 1800 ++++++++++++++++++++++
drivers/net/wireless/orinoco/spectrum_cs.c | 7 +-
drivers/net/wireless/orinoco/wext.c | 6 +-
drivers/net/wireless/p54/main.c | 3 +-
drivers/net/wireless/p54/p54pci.c | 16 +-
drivers/net/wireless/p54/txrx.c | 1 -
drivers/net/wireless/rt2x00/Kconfig | 4 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 4 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2800.h | 11 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 91 +-
drivers/net/wireless/rt2x00/rt2800pci.c | 6 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 13 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 1 -
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 6 +-
drivers/net/wireless/rt2x00/rt61pci.c | 5 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/net/wireless/rtl818x/rtl8180_dev.c | 13 +-
drivers/net/wireless/rtl818x/rtl8187_dev.c | 10 +-
drivers/net/wireless/wl12xx/wl1251_main.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_rx.c | 6 -
drivers/net/wireless/wl12xx/wl1271_acx.c | 2 +-
drivers/net/wireless/wl12xx/wl1271_boot.c | 8 +-
drivers/net/wireless/wl12xx/wl1271_cmd.c | 14 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 2 +-
drivers/net/wireless/wl12xx/wl1271_main.c | 97 +-
drivers/ssb/driver_chipcommon.c | 2 +
drivers/ssb/main.c | 3 +
drivers/ssb/pci.c | 14 +-
drivers/ssb/sprom.c | 14 +
include/linux/nl80211.h | 5 +
include/linux/ssb/ssb.h | 4 +
include/linux/ssb/ssb_driver_chipcommon.h | 15 +
include/linux/ssb/ssb_regs.h | 239 ++--
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 21 +-
net/mac80211/cfg.c | 18 +-
net/mac80211/debugfs_sta.c | 65 +-
net/mac80211/driver-ops.h | 5 +-
net/mac80211/driver-trace.h | 9 +-
net/mac80211/ibss.c | 27 +-
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/main.c | 19 +-
net/mac80211/mlme.c | 21 +
net/mac80211/rx.c | 2 -
net/mac80211/scan.c | 53 +-
net/mac80211/sta_info.c | 17 +-
net/mac80211/status.c | 7 +
net/mac80211/tx.c | 5 +-
net/mac80211/work.c | 28 +-
net/wireless/core.c | 3 +-
net/wireless/nl80211.c | 4 +
140 files changed, 4751 insertions(+), 1368 deletions(-)
create mode 100644 drivers/net/wireless/iwlwifi/iwl-3945-debugfs.c
create mode 100644 drivers/net/wireless/iwlwifi/iwl-3945-debugfs.h
create mode 100644 drivers/net/wireless/libertas_tf/deb_defs.h
create mode 100644 drivers/net/wireless/orinoco/orinoco_usb.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2010-04-23.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Dmitry Torokhov @ 2010-05-05 20:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: virtualization@lists.linux-foundation.org, Pankaj Thakkar,
Christoph Hellwig, pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <201005052209.48465.arnd@arndb.de>
On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote:
> > > If you have any interesting in developing this further, do:
> > >
> > > (1) move the limited VF drivers directly into the kernel tree,
> > > talk to them through a normal ops vector
> >
> > [PT] This assumes that all the VF drivers would always be available.
> > Also we have to support windows and our current design supports it
> > nicely in an OS agnostic manner.
>
> Your approach assumes that the plugin is always available, which has
> exactly the same implications.
Since plugin[s] are carried by the host they are indeed always
available.
--
Dmitry
^ permalink raw reply
* Re: 3 packet TCP window limit?
From: Rick Jones @ 2010-05-05 20:23 UTC (permalink / raw)
To: dormando; +Cc: Brian Bloniarz, netdev
In-Reply-To: <alpine.LNX.2.00.1005051239290.28957@d>
dormando wrote:
>>This sounds like TCP slow start.
>>
>>http://en.wikipedia.org/wiki/Slow-start
>>
>>As far as tunables you might want to play with the initcwnd route
>>flag (see "ip route help")
>
> Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
> start / etc. However I couldn't find the damn tunable for it :)
I don't believe linux as yet has a damn tunable for it :)
> ssthresh/tso/etc didn't seem to unwedge it.
If they did, it would be a bug. In fact there *was* a bug "way back when" where
TSO being enabled caused the stack to ignore initcwd, but that was fixed circa
2.6.14. Until it was fixed (it was difficult to notice unless one was speaking
to a non-Linux reciever, since Linux receivers autotune the receive window) it
did some very nice things for SPECweb benchmark results :)
> Felt like describing it in the most generic way possible would help :)
>
> Other OS's appear to have a larger initcwnd.
Names? Values?
> As do commercial load balancers.
Names? Values?
> The default of 3 seems to be tuned for 56k dialup modems. I'm a
> little surprised that none of the pluggable TCP congestion control
> algorithms changed this value. I went through all of them except for
> tcp_yeah.
The initcwnd comes from IETF RFCs and their "thou shalts" and "thou shalt nots."
As you note below, Google et al seek to alter/extend the RFCs. That is an
ongoing discussion in some of the ietf related mailing lists.
rick jones
> Anyway, thanks and sorry for the nearly off-topic post here. I see some
> google papers on bumping initcwnd to 10... but I guess that's not linux's
> deal yet.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Arnd Bergmann @ 2010-05-05 20:09 UTC (permalink / raw)
To: virtualization
Cc: Pankaj Thakkar, Christoph Hellwig, Dmitry Torokhov,
pv-drivers@vmware.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <F1354E79A137A24CBA60059AA65CB1B802A235C535@EXCH-MBX-2.vmware.com>
On Wednesday 05 May 2010 19:47:10 Pankaj Thakkar wrote:
> >
> > Forget about the licensing. Loading binary blobs written to a shim
> > layer is a complete pain in the ass and totally unsupportable, and
> > also uninteresting because of the overhead.
>
> [PT] Why do you think it is unsupportable? How different is it from any module
> written against a well maintained interface? What overhead are you talking about?
We have the right number of module loaders in the kernel: one. If you
add another one, you're doubling the amount of code that anyone
working on that code needs to know about.
> > If you have any interesting in developing this further, do:
> >
> > (1) move the limited VF drivers directly into the kernel tree,
> > talk to them through a normal ops vector
> [PT] This assumes that all the VF drivers would always be available.
> Also we have to support windows and our current design supports it
> nicely in an OS agnostic manner.
Your approach assumes that the plugin is always available, which has
exactly the same implications.
> > (2) get rid of the whole shim crap and instead integrate the limited
> > VF driver with the full VF driver we already have, instead of
> > duplicating the code
> [PT] Having a full VF driver adds a lot of dependency on the guest VM
> and this is what NPA tries to avoid.
If you have the limited driver for some hardware that does not have
the real thing, we could still ship just that. I would however guess
that most vendors are interested in not just running in vmware but
also other hypervisors that still require the full driver, so that
case would be rare, especially in the long run.
Arnd
^ permalink raw reply
* Re: 3 packet TCP window limit?
From: dormando @ 2010-05-05 20:01 UTC (permalink / raw)
To: Brian Bloniarz; +Cc: netdev
In-Reply-To: <4BE171EC.20904@athenacr.com>
> This sounds like TCP slow start.
>
> http://en.wikipedia.org/wiki/Slow-start
>
> As far as tunables you might want to play with the initcwnd route
> flag (see "ip route help")
Ah, yes, initcwnd was it. I'm well aware of TCP Congestion control / slow
start / etc. However I couldn't find the damn tunable for it :)
ssthresh/tso/etc didn't seem to unwedge it. Felt like describing it in the
most generic way possible would help :)
Other OS's appear to have a larger initcwnd. As do commercial load
balancers. The default of 3 seems to be tuned for 56k dialup modems. I'm a
little surprised that none of the pluggable TCP congestion control
algorithms changed this value. I went through all of them except for
tcp_yeah.
Anyway, thanks and sorry for the nearly off-topic post here. I see some
google papers on bumping initcwnd to 10... but I guess that's not linux's
deal yet.
^ permalink raw reply
* Re: [PATCH/RFC] cxgb4: Add MAINTAINERS info
From: Steve Wise @ 2010-05-05 19:59 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dm-ut6Up61K2wZBDgjK7y7TUQ
In-Reply-To: <adawrvijhpq.fsf_-_-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
Looks good to me.
Steve.
Roland Dreier wrote:
> Hi guys, does this info for cxgb4/iw_cxgb4 (pretty much copied from
> cxgb3, except with Dimitris instead of Divy) look right? If so I'll add
> it to my tree.
>
> Thanks,
> Roland
> ---
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7a9ccda..a00231b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1719,6 +1719,20 @@ W: http://www.openfabrics.org
> S: Supported
> F: drivers/infiniband/hw/cxgb3/
>
> +CXGB4 ETHERNET DRIVER (CXGB4)
> +M: Dimitris Michailidis <dm-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
> +L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +W: http://www.chelsio.com
> +S: Supported
> +F: drivers/net/cxgb4/
> +
> +CXGB4 IWARP RNIC DRIVER (IW_CXGB4)
> +M: Steve Wise <swise-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
> +L: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +W: http://www.openfabrics.org
> +S: Supported
> +F: drivers/infiniband/hw/cxgb4/
> +
> CYBERPRO FB DRIVER
> M: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
>
--
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 2/6] netns: Teach network device kobjects which namespace they are in.
From: Eric W. Biederman @ 2010-05-05 19:56 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Greg Kroah-Hartman, Kay Sievers, linux-kernel, Tejun Heo,
Cornelia Huck, Eric Dumazet, Benjamin LaHaise, netdev,
David Miller
In-Reply-To: <20100505151746.GA15654@us.ibm.com>
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
>> diff --git a/net/Kconfig b/net/Kconfig
>> index 041c35e..265e33b 100644
>> --- a/net/Kconfig
>> +++ b/net/Kconfig
>> @@ -45,6 +45,14 @@ config COMPAT_NETLINK_MESSAGES
>>
>> menu "Networking options"
>>
>> +config NET_NS
>> + bool "Network namespace support"
>> + default n
>> + depends on EXPERIMENTAL && NAMESPACES
>> + help
>> + Allow user space to create what appear to be multiple instances
>> + of the network stack.
>> +
>
> Hi Eric,
>
> I'm confused - NET_NS is defined in init/Kconfig right now. Is the tree
> you're working from very different from mine, or is this the unfortunate
> rekult of the patches sitting so long?
Old patches, nothing that complains when you make a mistake like this,
and apparently I have a blind spot in my personal code review.
At one point it was not possible to enable the network namespace until
the sysfs stuff was enabled, but things have been going on long enough
that we worked around that restriction.
>> source "net/packet/Kconfig"
>> source "net/unix/Kconfig"
>> source "net/xfrm/Kconfig"
>> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
>> index 099c753..1b98e36 100644
>> --- a/net/core/net-sysfs.c
>> +++ b/net/core/net-sysfs.c
>> @@ -13,7 +13,9 @@
>> #include <linux/kernel.h>
>> #include <linux/netdevice.h>
>> #include <linux/if_arp.h>
>> +#include <linux/nsproxy.h>
>> #include <net/sock.h>
>> +#include <net/net_namespace.h>
>> #include <linux/rtnetlink.h>
>> #include <linux/wireless.h>
>> #include <net/wext.h>
>> @@ -466,6 +468,37 @@ static struct attribute_group wireless_group = {
>> };
>> #endif
>>
>> +static const void *net_current_ns(void)
>> +{
>> + return current->nsproxy->net_ns;
>> +}
>> +
>> +static const void *net_initial_ns(void)
>> +{
>> + return &init_net;
>> +}
>> +
>> +static const void *net_netlink_ns(struct sock *sk)
>> +{
>> + return sock_net(sk);
>> +}
>> +
>> +static struct kobj_ns_type_operations net_ns_type_operations = {
>> + .type = KOBJ_NS_TYPE_NET,
>> + .current_ns = net_current_ns,
>> + .netlink_ns = net_netlink_ns,
>> + .initial_ns = net_initial_ns,
>> +};
>> +
>> +static void net_kobj_ns_exit(struct net *net)
>> +{
>> + kobj_ns_exit(KOBJ_NS_TYPE_NET, net);
>> +}
>> +
>> +static struct pernet_operations sysfs_net_ops = {
>> + .exit = net_kobj_ns_exit,
>> +};
>> +
>> #endif /* CONFIG_SYSFS */
>
> ...
>
>> int netdev_kobject_init(void)
>> {
>> + kobj_ns_type_register(&net_ns_type_operations);
>> +#ifdef CONFIG_SYSFS
>> + register_pernet_subsys(&sysfs_net_ops);
>> +#endif
>> return class_register(&net_class);
>
> I think the kobj_ns_type_register() needs to be under
> ifdef CONFIG_SYSFS as well, bc net_ns_type_operations is defined
> under ifdef CONFIG_SYSFS.
kobj_ns_type_register should not be under CONFIG_SYSFS. Which means
that kobj_ns_type_operations needs not to be under CONFIG_SYSFS as
well. That you for spotting that bug.
Grr.
Eric
^ permalink raw reply
* Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Pankaj Thakkar @ 2010-05-05 19:44 UTC (permalink / raw)
To: Avi Kivity
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
virtualization@lists.linux-foundation.org, pv-drivers@vmware.com,
Shreyas Bhatewara
In-Reply-To: <4BE1B217.80600@redhat.com>
On Wed, May 05, 2010 at 10:59:51AM -0700, Avi Kivity wrote:
> Date: Wed, 5 May 2010 10:59:51 -0700
> From: Avi Kivity <avi@redhat.com>
> To: Pankaj Thakkar <pthakkar@vmware.com>
> CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
> "virtualization@lists.linux-foundation.org"
> <virtualization@lists.linux-foundation.org>,
> "pv-drivers@vmware.com" <pv-drivers@vmware.com>,
> Shreyas Bhatewara <sbhatewara@vmware.com>
> Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
>
> On 05/05/2010 02:02 AM, Pankaj Thakkar wrote:
> > 2. Hypervisor control: All control operations from the guest such as programming
> > MAC address go through the hypervisor layer and hence can be subjected to
> > hypervisor policies. The PF driver can be further used to put policy decisions
> > like which VLAN the guest should be on.
> >
>
> Is this enforced? Since you pass the hardware through, you can't rely
> on the guest actually doing this, yes?
We don't pass the whole VF to the guest. Only the BAR which is responsible for
TX/RX/intr is mapped into guest space. The interface between the shell and
plugin only allows to do operations related to TX and RX such as send a packet
to the VF, allocate RX buffers, indicate a packet upto the shell. All control
operations are handled by the shell and the shell does what the existing
vmxnet3 drivers does (touch a specific register and let the device emulation do
the work). When a VF is mapped to the guest the hypervisor knows this and
programs the h/w accordingly on behalf of the shell. So for example if the VM
does a MAC address change inside the guest, the shell would write to
VMXNET3_REG_MAC{L|H} registers which would trigger the device emulation to read
the new mac address and update its internal virtual port information for the
virtual switch and if the VF is mapped it would also program the embedded
switch RX filters to reflect the new mac address.
>
> > The plugin image is provided by the IHVs along with the PF driver and is
> > packaged in the hypervisor. The plugin image is OS agnostic and can be loaded
> > either into a Linux VM or a Windows VM. The plugin is written against the Shell
> > API interface which the shell is responsible for implementing. The API
> > interface allows the plugin to do TX and RX only by programming the hardware
> > rings (along with things like buffer allocation and basic initialization). The
> > virtual machine comes up in paravirtualized/emulated mode when it is booted.
> > The hypervisor allocates the VF and other resources and notifies the shell of
> > the availability of the VF. The hypervisor injects the plugin into memory
> > location specified by the shell. The shell initializes the plugin by calling
> > into a known entry point and the plugin initializes the data path. The control
> > path is already initialized by the PF driver when the VF is allocated. At this
> > point the shell switches to using the loaded plugin to do all further TX and RX
> > operations. The guest networking stack does not participate in these operations
> > and continues to function normally. All the control operations continue being
> > trapped by the hypervisor and are directed to the PF driver as needed. For
> > example, if the MAC address changes the hypervisor updates its internal state
> > and changes the state of the embedded switch as well through the PF control
> > API.
> >
>
> This is essentially a miniature network stack with a its own mini
> bonding layer, mini hotplug, and mini API, except s/API/ABI/. Is this a
> correct view?
To some extent yes but there is no complicated bonding nor there is any thing
like a PCI hotplug. The shell interface is small and the OS always interacts
with the shell as the main driver. Based on the underlying VF the plugin
changes and this plugin as well is really small. Our vmxnet3 s/w plugin is
about 1300 lines with whitespaces and comments and the Intel Kawela plugin is
about 1100 lines with whitspaces and comments. The design principle is to put
more of the complexity related to initialization/control into the PF driver
rather than in plugin.
>
> If so, the Linuxy approach would be to use the ordinary drivers and the
> Linux networking API, and hide the bond setup using namespaces. The
> bond driver, or perhaps a new, similar, driver can be enhanced to
> propagate ethtool commands to its (hidden) components, and to have a
> control channel with the hypervisor.
>
> This would make the approach hypervisor agnostic, you're just pairing
> two devices and presenting them to the rest of the stack as a single device.
>
> > We have reworked our existing Linux vmxnet3 driver to accomodate NPA by
> > splitting the driver into two parts: Shell and Plugin. The new split driver is
> >
>
> So the Shell would be the reworked or new bond driver, and Plugins would
> be ordinary Linux network drivers.
In NPA we do not rely on the guest OS to provide any of these services like
bonding or PCI hotplug. We don't rely on the guest OS to unmap a VF and switch
a VM out of passthrough. In a bonding approach that becomes an issue you can't
just yank a device from underneath, you have to wait for the OS to process the
request and switch from using VF to the emulated device and this makes the
hypervisor dependent on the guest OS. Also we don't rely on the presence of all
the drivers inside the guest OS (be it Linux or Windows), the ESX hypervisor
carries all the plugins and the PF drivers and injects the right one as needed.
These plugins are guest agnostic and the IHVs do not have to write plugins for
different OS.
Thanks,
-pankaj
^ permalink raw reply
* Re: linear sk_buff
From: Phil Sutter @ 2010-05-05 19:32 UTC (permalink / raw)
To: netdev
In-Reply-To: <o2kdac45061005051212na062f611m1c87240c367b5d38@mail.gmail.com>
Hi,
On Wed, May 05, 2010 at 10:12:06PM +0300, Mark Ryden wrote:
> I would appreciate if someone in this mailing list can say in a
> sentence or two what is a linear
> sk_buff and what is a non linear sk_buff; does it has to do with fragmentation?
> (I am sure that many know the answer, but I am confused and googling
> made me overconfused)
As far as I can tell, linear and non-linear sk_buffs differ in how the
data they contain is kept internally. Linear sk_buffs are trivial, it's
data resides in one, continuous block. In non-linear sk_buffs, data is
spread across multiple junks, organised in a data structure comparable
to e.g. scatterlists.
For further information, I'd highly recommend David Miller's "how SKBs
work": http://vger.kernel.org/~davem/skb.html .
Greetings, Phil
^ permalink raw reply
* Re: linear sk_buff
From: Rémi Denis-Courmont @ 2010-05-05 19:35 UTC (permalink / raw)
To: Mark Ryden; +Cc: netdev
In-Reply-To: <o2kdac45061005051212na062f611m1c87240c367b5d38@mail.gmail.com>
Le mercredi 5 mai 2010 22:12:06 Mark Ryden, vous avez écrit :
> Hello,
> I would appreciate if someone in this mailing list can say in a
> sentence or two what is a linear
> sk_buff and what is a non linear sk_buff; does it has to do with
> fragmentation? (I am sure that many know the answer, but I am confused and
> googling made me overconfused)
A linear sk_buff is one that has no memory pages and no fragments sk_buff.
Such a buffer is made of a contiguous portion of the (kernel) memory.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* [PATCH v2] sctp: Fix a race between ICMP protocol unreachable and connect()
From: Vlad Yasevich @ 2010-05-05 19:36 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, Vlad Yasevich
In-Reply-To: <1273087783-18250-1-git-send-email-vladislav.yasevich@hp.com>
[.. removed leftover debuggin printk. should probably be queued for stable
as well... ]
ICMP protocol unreachable handling completely disregarded
the fact that the user may have locket the socket. It proceeded
to destroy the association, even though the user may have
held the lock and had a ref on the association. This resulted
in the following:
Attempt to release alive inet socket f6afcc00
=========================
[ BUG: held lock freed! ]
-------------------------
somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
there!
(sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
1 lock held by somenu/2672:
#0: (sk_lock-AF_INET){+.+.+.}, at: [<c122098a>] sctp_connect+0x13/0x4c
stack backtrace:
Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
Call Trace:
[<c1232266>] ? printk+0xf/0x11
[<c1038553>] debug_check_no_locks_freed+0xce/0xff
[<c10620b4>] kmem_cache_free+0x21/0x66
[<c1185f25>] __sk_free+0x9d/0xab
[<c1185f9c>] sk_free+0x1c/0x1e
[<c1216e38>] sctp_association_put+0x32/0x89
[<c1220865>] __sctp_connect+0x36d/0x3f4
[<c122098a>] ? sctp_connect+0x13/0x4c
[<c102d073>] ? autoremove_wake_function+0x0/0x33
[<c12209a8>] sctp_connect+0x31/0x4c
[<c11d1e80>] inet_dgram_connect+0x4b/0x55
[<c11834fa>] sys_connect+0x54/0x71
[<c103a3a2>] ? lock_release_non_nested+0x88/0x239
[<c1054026>] ? might_fault+0x42/0x7c
[<c1054026>] ? might_fault+0x42/0x7c
[<c11847ab>] sys_socketcall+0x6d/0x178
[<c10da994>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c1002959>] syscall_call+0x7/0xb
This was because the sctp_wait_for_connect() would aqcure the socket
lock and then proceed to release the last reference count on the
association, thus cause the fully destruction path to finish freeing
the socket.
The simplest solution is to start a very short timer in case the socket
is owned by user. When the timer expires, we can do some verification
and be able to do the release properly.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
include/net/sctp/sm.h | 1 +
include/net/sctp/structs.h | 3 +++
net/sctp/input.c | 22 ++++++++++++++++++----
net/sctp/sm_sideeffect.c | 35 +++++++++++++++++++++++++++++++++++
net/sctp/transport.c | 2 ++
5 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
index 851c813..61d73e3 100644
--- a/include/net/sctp/sm.h
+++ b/include/net/sctp/sm.h
@@ -279,6 +279,7 @@ int sctp_do_sm(sctp_event_t event_type, sctp_subtype_t subtype,
/* 2nd level prototypes */
void sctp_generate_t3_rtx_event(unsigned long peer);
void sctp_generate_heartbeat_event(unsigned long peer);
+void sctp_generate_proto_unreach_event(unsigned long peer);
void sctp_ootb_pkt_free(struct sctp_packet *);
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 597f8e2..219043a 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -1010,6 +1010,9 @@ struct sctp_transport {
/* Heartbeat timer is per destination. */
struct timer_list hb_timer;
+ /* Timer to handle ICMP proto unreachable envets */
+ struct timer_list proto_unreach_timer;
+
/* Since we're using per-destination retransmission timers
* (see above), we're also using per-destination "transmitted"
* queues. This probably ought to be a private struct
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 2a57018..ea21924 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -440,11 +440,25 @@ void sctp_icmp_proto_unreachable(struct sock *sk,
{
SCTP_DEBUG_PRINTK("%s\n", __func__);
- sctp_do_sm(SCTP_EVENT_T_OTHER,
- SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
- asoc->state, asoc->ep, asoc, t,
- GFP_ATOMIC);
+ if (sock_owned_by_user(sk)) {
+ if (timer_pending(&t->proto_unreach_timer))
+ return;
+ else {
+ if (!mod_timer(&t->proto_unreach_timer,
+ jiffies + (HZ/20)))
+ sctp_association_hold(asoc);
+ }
+
+ } else {
+ if (timer_pending(&t->proto_unreach_timer) &&
+ del_timer(&t->proto_unreach_timer))
+ sctp_association_put(asoc);
+ sctp_do_sm(SCTP_EVENT_T_OTHER,
+ SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
+ asoc->state, asoc->ep, asoc, t,
+ GFP_ATOMIC);
+ }
}
/* Common lookup code for icmp/icmpv6 error handler. */
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index d5ae450..eb1f42f 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -397,6 +397,41 @@ out_unlock:
sctp_transport_put(transport);
}
+/* Handle the timeout of the ICMP protocol unreachable timer. Trigger
+ * the correct state machine transition that will close the association.
+ */
+void sctp_generate_proto_unreach_event(unsigned long data)
+{
+ struct sctp_transport *transport = (struct sctp_transport *) data;
+ struct sctp_association *asoc = transport->asoc;
+
+ sctp_bh_lock_sock(asoc->base.sk);
+ if (sock_owned_by_user(asoc->base.sk)) {
+ SCTP_DEBUG_PRINTK("%s:Sock is busy.\n", __func__);
+
+ /* Try again later. */
+ if (!mod_timer(&transport->proto_unreach_timer,
+ jiffies + (HZ/20)))
+ sctp_association_hold(asoc);
+ goto out_unlock;
+ }
+
+ /* Is this structure just waiting around for us to actually
+ * get destroyed?
+ */
+ if (asoc->base.dead)
+ goto out_unlock;
+
+ sctp_do_sm(SCTP_EVENT_T_OTHER,
+ SCTP_ST_OTHER(SCTP_EVENT_ICMP_PROTO_UNREACH),
+ asoc->state, asoc->ep, asoc, transport, GFP_ATOMIC);
+
+out_unlock:
+ sctp_bh_unlock_sock(asoc->base.sk);
+ sctp_association_put(asoc);
+}
+
+
/* Inject a SACK Timeout event into the state machine. */
static void sctp_generate_sack_event(unsigned long data)
{
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index be4d63d..4a36803 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -108,6 +108,8 @@ static struct sctp_transport *sctp_transport_init(struct sctp_transport *peer,
(unsigned long)peer);
setup_timer(&peer->hb_timer, sctp_generate_heartbeat_event,
(unsigned long)peer);
+ setup_timer(&peer->proto_unreach_timer,
+ sctp_generate_proto_unreach_event, (unsigned long)peer);
/* Initialize the 64-bit random nonce sent with heartbeat. */
get_random_bytes(&peer->hb_nonce, sizeof(peer->hb_nonce));
--
1.6.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox