* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Dave Airlie @ 2010-10-19 4:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <1287459219.16971.352.camel@gandalf.stny.rr.com>
>>
>> like I'm sure the intersection of this driver and reality are getting
>> quite limited, but its still a userspace ABI change and needs to be
>> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
>> old driver/API.
>
> Thus, you are saying that this will break for people with older user
> apps and have a newer kernel?
There are two drivers here:
i810
i830
The i830 case is the case I care less about since the ABI is only used
by older userspace and i915 provides a replacement.
the i810 case ABI is still in use today by distro userspaces that are
still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6
Beta etc.
I've snipped the rest of the argument on the grounds you are
conflating two cases that aren't the same.
>
>>
>> Well the thing is doing the work right is a non-trivial task and just
>> dropping support only screws the people using the hardware,
>> it doesn't place any burden on the distro developers to fix it up. If
>> people are really serious about making the BKL go away completely, I
>> think the onus should be on them to fix the drivers not on the users
>> who are using it, like I'm guessing if this gets broken the bug will
>> end up in Novell or RH bugzilla in a year and nobody will ever see it.
>
> Well the problem comes down to testing it. I don't know of any developer
> that is removing the BKL that actually owns hardware to test out these
> broken drivers. And for the change not being trivial, means that there's
> no way to do in correctly.
>
So we can drop i830 using deprecation, however its pointless since the
fix for i810 is the same fix for i830 if we can work out the fix.
Well the way to do it correctly is make it so if the driver is
initialised and we do an SMP transition we warn the users, or we make
BROKEN_ON_SMP into a runtime thing that warns when the driver is
loaded on an SMP system. The intersection of SMP and this hardware is
definitely a very very small number and a lot more workable.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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
* [PATCH 3/3 v2] net: allocate tx queues in register_netdevice
From: Tom Herbert @ 2010-10-19 4:04 UTC (permalink / raw)
To: davem, netdev; +Cc: bhutchings, eric.dumazet
This patch introduces netif_alloc_netdev_queues which is called from
register_device instead of alloc_netdev_mq. This makes TX queue
allocation symmetric with RX allocation. Also, queue locks allocation
is done in netdev_init_one_queue. Change set_real_num_tx_queues to
fail if requested number < 1 or greater than number of allocated
queues.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/netdevice.h | 4 +-
net/core/dev.c | 106 ++++++++++++++++++++++----------------------
2 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 14fbb04..880d565 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1696,8 +1696,8 @@ static inline int netif_is_multiqueue(const struct net_device *dev)
return dev->num_tx_queues > 1;
}
-extern void netif_set_real_num_tx_queues(struct net_device *dev,
- unsigned int txq);
+extern int netif_set_real_num_tx_queues(struct net_device *dev,
+ unsigned int txq);
#ifdef CONFIG_RPS
extern int netif_set_real_num_rx_queues(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index d33adec..7ae5c7e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1553,18 +1553,20 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
* Routine to help set real_num_tx_queues. To avoid skbs mapped to queues
* greater then real_num_tx_queues stale skbs on the qdisc must be flushed.
*/
-void netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
+int netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
{
- unsigned int real_num = dev->real_num_tx_queues;
+ if (txq < 1 || txq > dev->num_tx_queues)
+ return -EINVAL;
- if (unlikely(txq > dev->num_tx_queues))
- ;
- else if (txq > real_num)
- dev->real_num_tx_queues = txq;
- else if (txq < real_num) {
- dev->real_num_tx_queues = txq;
- qdisc_reset_all_tx_gt(dev, txq);
+ if (dev->reg_state == NETREG_REGISTERED) {
+ ASSERT_RTNL();
+
+ if (txq < dev->real_num_tx_queues)
+ qdisc_reset_all_tx_gt(dev, txq);
}
+
+ dev->real_num_tx_queues = txq;
+ return 0;
}
EXPORT_SYMBOL(netif_set_real_num_tx_queues);
@@ -4928,20 +4930,6 @@ static void rollback_registered(struct net_device *dev)
rollback_registered_many(&single);
}
-static void __netdev_init_queue_locks_one(struct net_device *dev,
- struct netdev_queue *dev_queue,
- void *_unused)
-{
- spin_lock_init(&dev_queue->_xmit_lock);
- netdev_set_xmit_lockdep_class(&dev_queue->_xmit_lock, dev->type);
- dev_queue->xmit_lock_owner = -1;
-}
-
-static void netdev_init_queue_locks(struct net_device *dev)
-{
- netdev_for_each_tx_queue(dev, __netdev_init_queue_locks_one, NULL);
-}
-
unsigned long netdev_fix_features(unsigned long features, const char *name)
{
/* Fix illegal SG+CSUM combinations. */
@@ -5034,6 +5022,41 @@ static int netif_alloc_rx_queues(struct net_device *dev)
return 0;
}
+static int netif_alloc_netdev_queues(struct net_device *dev)
+{
+ unsigned int count = dev->num_tx_queues;
+ struct netdev_queue *tx;
+
+ BUG_ON(count < 1);
+
+ tx = kcalloc(count, sizeof(struct netdev_queue), GFP_KERNEL);
+ if (!tx) {
+ pr_err("netdev: Unable to allocate %u tx queues.\n",
+ count);
+ return -ENOMEM;
+ }
+ dev->_tx = tx;
+ return 0;
+}
+
+static void netdev_init_one_queue(struct net_device *dev,
+ struct netdev_queue *queue,
+ void *_unused)
+{
+ queue->dev = dev;
+
+ /* Initialize queue lock */
+ spin_lock_init(&queue->_xmit_lock);
+ netdev_set_xmit_lockdep_class(&queue->_xmit_lock, dev->type);
+ queue->xmit_lock_owner = -1;
+}
+
+static void netdev_init_queues(struct net_device *dev)
+{
+ netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
+ spin_lock_init(&dev->tx_global_lock);
+}
+
/**
* register_netdevice - register a network device
* @dev: device to register
@@ -5067,7 +5090,6 @@ int register_netdevice(struct net_device *dev)
spin_lock_init(&dev->addr_list_lock);
netdev_set_addr_lockdep_class(dev);
- netdev_init_queue_locks(dev);
dev->iflink = -1;
@@ -5075,6 +5097,12 @@ int register_netdevice(struct net_device *dev)
if (ret)
goto out;
+ ret = netif_alloc_netdev_queues(dev);
+ if (ret)
+ goto out;
+
+ netdev_init_queues(dev);
+
/* Init, if this function is available */
if (dev->netdev_ops->ndo_init) {
ret = dev->netdev_ops->ndo_init(dev);
@@ -5456,19 +5484,6 @@ struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
}
EXPORT_SYMBOL(dev_get_stats);
-static void netdev_init_one_queue(struct net_device *dev,
- struct netdev_queue *queue,
- void *_unused)
-{
- queue->dev = dev;
-}
-
-static void netdev_init_queues(struct net_device *dev)
-{
- netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
- spin_lock_init(&dev->tx_global_lock);
-}
-
struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
{
struct netdev_queue *queue = dev_ingress_queue(dev);
@@ -5480,7 +5495,6 @@ struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
if (!queue)
return NULL;
netdev_init_one_queue(dev, queue, NULL);
- __netdev_init_queue_locks_one(dev, queue, NULL);
queue->qdisc = &noop_qdisc;
queue->qdisc_sleeping = &noop_qdisc;
rcu_assign_pointer(dev->ingress_queue, queue);
@@ -5502,7 +5516,6 @@ struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
void (*setup)(struct net_device *), unsigned int queue_count)
{
- struct netdev_queue *tx;
struct net_device *dev;
size_t alloc_size;
struct net_device *p;
@@ -5530,20 +5543,12 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
return NULL;
}
- tx = kcalloc(queue_count, sizeof(struct netdev_queue), GFP_KERNEL);
- if (!tx) {
- printk(KERN_ERR "alloc_netdev: Unable to allocate "
- "tx qdiscs.\n");
- goto free_p;
- }
-
-
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
dev->pcpu_refcnt = alloc_percpu(int);
if (!dev->pcpu_refcnt)
- goto free_tx;
+ goto free_p;
if (dev_addr_init(dev))
goto free_pcpu;
@@ -5553,7 +5558,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev_net_set(dev, &init_net);
- dev->_tx = tx;
dev->num_tx_queues = queue_count;
dev->real_num_tx_queues = queue_count;
@@ -5564,8 +5568,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev->gso_max_size = GSO_MAX_SIZE;
- netdev_init_queues(dev);
-
INIT_LIST_HEAD(&dev->ethtool_ntuple_list.list);
dev->ethtool_ntuple_list.count = 0;
INIT_LIST_HEAD(&dev->napi_list);
@@ -5576,8 +5578,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
strcpy(dev->name, name);
return dev;
-free_tx:
- kfree(tx);
free_pcpu:
free_percpu(dev->pcpu_refcnt);
free_p:
--
1.7.1
^ permalink raw reply related
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Dave Airlie @ 2010-10-19 4:52 UTC (permalink / raw)
To: Theodore Kilgore
Cc: Steven Rostedt, Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <alpine.LNX.2.00.1010182342120.31740@banach.math.auburn.edu>
> I might be able to find some hardware still lying around here that uses an
> i810. Not sure unless I go hunting it. But I get the impression that if
> the kernel is a single-CPU kernel there is not any problem anyway? Don't
> distros offer a non-smp kernel as an installation option in case the user
> needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
Dave.
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Theodore Kilgore @ 2010-10-19 5:00 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dave Airlie, Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <1287459219.16971.352.camel@gandalf.stny.rr.com>
On Mon, 18 Oct 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH <greg@kroah.com> wrote:
>
> > > So, there is no need for the i830 driver? Can it just be removed
> > > because i915 works instead?
> >
> > No because it provides a different userspace ABI to the i915 driver to
> > a different userspace X driver etc.
> >
> > like I'm sure the intersection of this driver and reality are getting
> > quite limited, but its still a userspace ABI change and needs to be
> > treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
> > old driver/API.
>
> Thus, you are saying that this will break for people with older user
> apps and have a newer kernel?
>
> >
> > >> So it really only leaves the problem case of what do distros do if we
> > >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
> > >> when you boot the SMP kernels on UP they don't run as SMP so not
> > >> having the driver load on those is a problem. Maybe we just need some
> > >> sort of warn on smp if a smp unfriendly driver is loaded and we
> > >> transition to SMP mode. Though this sounds like either (a) something
> > >> we do now and I don't about it, (b) work.
> > >
> > > So you are saying that just because distros will never build such a
> > > thing, we should keep it building for SMP mode? Why not prevent it from
> > > being built and if a distro really cares, then they will pony up the
> > > development to fix the driver up?
> >
> > Distros build the driver now even it it didn't work on SMP it wouldn't
> > matter to the 99% of people who have this hw since it can't suppport
> > SMP except in some corner cases. So not building for SMP is the same
> > as just throwing it out of the kernel since most people don't run
> > kernel.org kernels, and shouldn't have to just to get a driver for
> > some piece of hardware that worked fine up until now.
>
> Ah! Exactly! Thus, those that do not run kernel.org kernels are using a
> distro kernel. Wont these same people use the distro userspace? That is,
> if they have upgraded their kernel, most likely, they also update their
> X interface.
>
> >
> > Look at this from a user who has this hardware pov, it works for them
> > now with a distro kernel, us breaking it isn't going to help that user
> > or make any distro care, its just going to screw over the people who
> > are actually using it.
>
> But they can use the i915 driver instead, because they are using the
> newer userspace apps.
>
> >
> > > In other words, if someone really cares, then they will do the work,
> > > otherwise why worry? Especially as it seems that no one here is going
> > > to do it, right?
> >
> > Well the thing is doing the work right is a non-trivial task and just
> > dropping support only screws the people using the hardware,
> > it doesn't place any burden on the distro developers to fix it up. If
> > people are really serious about making the BKL go away completely, I
> > think the onus should be on them to fix the drivers not on the users
> > who are using it, like I'm guessing if this gets broken the bug will
> > end up in Novell or RH bugzilla in a year and nobody will ever see it.
>
> Well the problem comes down to testing it. I don't know of any developer
> that is removing the BKL that actually owns hardware to test out these
> broken drivers. And for the change not being trivial, means that there's
> no way to do in correctly.
>
> -- Steve
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Theodore Kilgore
^ permalink raw reply
* Re: [PATCH 1/3 v2] net: fail alloc_netdev_mq if queue count < 1
From: Eric Dumazet @ 2010-10-19 5:02 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, bhutchings
In-Reply-To: <alpine.DEB.1.00.1010182053060.6676@pokey.mtv.corp.google.com>
Le lundi 18 octobre 2010 à 20:55 -0700, Tom Herbert a écrit :
> In alloc_netdev_mq fail if requested queue_count < 1.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/core/dev.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH] bonding: various fixes for bonding, netpoll & netconsole (v3)
From: Cong Wang @ 2010-10-19 5:21 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, netdev, bonding-devel, fubar, andy
In-Reply-To: <20101018.082529.115920035.davem@davemloft.net>
On 10/18/10 23:25, David Miller wrote:
> From: nhorman@tuxdriver.com
> Date: Wed, 13 Oct 2010 22:01:48 -0400
>
>> Version 3, taking the following changes into account:
> ...
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>
> Applied, thanks Neil.
Hi, David,
Which tree do you apply this patchset to? I checked both net-2.6
and net-next-2.6, neither of them has these patches.
I have some patches based on these patches.
Thanks.
^ permalink raw reply
* [PATCH] net: unix: make some variables constant
From: Changli Gao @ 2010-10-19 5:24 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Changli Gao
And since ctl_table.data is initialized later, we don't need to initialize
the data member of the template variable unix_table.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/unix/sysctl_net_unix.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
index 397cffe..1114ccc 100644
--- a/net/unix/sysctl_net_unix.c
+++ b/net/unix/sysctl_net_unix.c
@@ -15,10 +15,9 @@
#include <net/af_unix.h>
-static ctl_table unix_table[] = {
+const static ctl_table unix_table[] = {
{
.procname = "max_dgram_qlen",
- .data = &init_net.unx.sysctl_max_dgram_qlen,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec
@@ -26,7 +25,7 @@ static ctl_table unix_table[] = {
{ }
};
-static struct ctl_path unix_path[] = {
+const static struct ctl_path unix_path[] = {
{ .procname = "net", },
{ .procname = "unix", },
{ },
^ permalink raw reply related
* Re: [PATCH v6] Gigabit Ethernet driver of Topcliff PCH
From: Masayuki Ohtake @ 2010-10-19 5:30 UTC (permalink / raw)
To: seedshope
Cc: David S. Miller, Randy Dunlap, John Linn, Ralf Baechle,
Kristoffer Glembo, Maxime Bizon, Greg Rose, ML netdev, LKML,
Toshiharu Okada, Takahiro Shimizu, Tomoya Morinaga, Wang, Qi,
Wang, Yong Y, Andrew, Intel OTC, Foster, Margie, MeeGo
In-Reply-To: <AANLkTinedgQJq04PHdGmZqs4p6Du4PA16QC2JNTaGhAa@mail.gmail.com>
Hi seedshope,
>why it is need to compare the INT_EN bit?
>As general, the pch_gbe_intr function was call,the interrupt is enable.
>In addition to the interrupt generate, what other conditions would call the interrupt function?
PCI devices in Topcliff IOH are connected with external PCI Express through logical PCI bus.
In Topcliff IOH, more PCI devices are sharing interruption.
Gigabit Ethernet device and USB Host are sharing interruption.
The pch_gbe_intr function is called on condition of others.
So, the comparison with INT_EN bit is necessary.
>resently , I fail to test the kgdboe on the gbe driver.
>The pch_gbe_netpoll will call the pch_gbe_intr function.
>The interruption will be disable before enter the pch_gbe_intr.
>So the pch_gbe_netpoll is fail for ever. Is it a bug?
I think it is not a bug.
The INT_EN bit is a value of Gigabit Ethernet device's register.
The interruption disable processing before pch_gbe_intr() in pch_gbe_netpoll() function is a disable_irq() function.
The disable_irq() function does not change the register of a Gigabit Ethernet device.
Best regards.
Masayuki Otake.
-----
Date: Mon, 18 Oct 2010 16:48:50 +0800
From: seedshope
Hi Masayuki,
>/**
> * pch_gbe_intr - Interrupt Handler
> * @irq: Interrupt number
> * @data: Pointer to a network interface device structure
> * Returns
> * - IRQ_HANDLED: Our interrupt
> * - IRQ_NONE: Not our interrupt
> */
>static irqreturn_t pch_gbe_intr(int irq, void *data)
>{
> struct net_device *netdev = data;
> struct pch_gbe_adapter *adapter = netdev_priv(netdev);
> struct pch_gbe_hw *hw = &adapter->hw;
> u32 int_st;
> u32 int_en;
>
> /* Check request status */
> int_st = ioread32(&hw->reg->INT_ST);
> int_st = int_st & ioread32(&hw->reg->INT_EN);
why it is need to compare the INT_EN bit? As general, the pch_gbe_intr function was call,the interrupt is enable. In
addition to the interrupt generate, what other conditions would call the interrupt function?
resently , I fail to test the kgdboe on the gbe driver. The pch_gbe_netpoll will call the pch_gbe_intr function. The
interruption will be disable before enter the pch_gbe_intr.
So the pch_gbe_netpoll is fail for ever. Is it a bug?
> /* When request status is no interruption factor */
> if (unlikely(!int_st))
> return IRQ_NONE; /* Not our interrupt. End processing. */
> pr_debug("%s occur int_st = 0x%08x\n", __func__, int_st);
> if (int_st & PCH_GBE_INT_RX_FRAME_ERR)
> adapter->stats.intr_rx_frame_err_count++;
> if (int_st & PCH_GBE_INT_RX_FIFO_ERR)
> adapter->stats.intr_rx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_RX_DMA_ERR)
> adapter->stats.intr_rx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TX_FIFO_ERR)
> adapter->stats.intr_tx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_TX_DMA_ERR)
> adapter->stats.intr_tx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TCPIP_ERR)
> adapter->stats.intr_tcpip_err_count++;
> /* When Rx descriptor is empty */
> if ((int_st & PCH_GBE_INT_RX_DSC_EMP)) {
> adapter->stats.intr_rx_dsc_empty_count++;
> pr_err("Rx descriptor is empty\n");
> int_en = ioread32(&hw->reg->INT_EN);
> iowrite32((int_en & ~PCH_GBE_INT_RX_DSC_EMP), &hw->reg->INT_EN);
> if (hw->mac.tx_fc_enable) {
> /* Set Pause packet */
> pch_gbe_mac_set_pause_packet(hw);
> }
> if ((int_en & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))
> == 0) {
> return IRQ_HANDLED;
> }
> }
>
> /* When request status is Receive interruption */
> if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))) {
> if (likely(napi_schedule_prep(&adapter->napi))) {
> /* Enable only Rx Descriptor empty */
> atomic_inc(&adapter->irq_sem);
> int_en = ioread32(&hw->reg->INT_EN);
> int_en &=
> ~(PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT);
> iowrite32(int_en, &hw->reg->INT_EN);
> /* Start polling for NAPI */
> __napi_schedule(&adapter->napi);
> }
> }
> pr_debug("return = 0x%08x INT_EN reg = 0x%08x\n",
> IRQ_HANDLED, ioread32(&hw->reg->INT_EN));
> return IRQ_HANDLED;
>}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Eric Dumazet @ 2010-10-19 5:47 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1287465842-2958-1-git-send-email-xiaosuo@gmail.com>
Le mardi 19 octobre 2010 à 13:24 +0800, Changli Gao a écrit :
> And since ctl_table.data is initialized later, we don't need to initialize
> the data member of the template variable unix_table.
>
The init cost is nothing, since its a data blob that must be there
anyway.
We could even avoid the kmemdup() if CONFIG_NET_NS is not set
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Stephen Hemminger @ 2010-10-19 6:03 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1287465842-2958-1-git-send-email-xiaosuo@gmail.com>
On Tue, 19 Oct 2010 13:24:02 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> And since ctl_table.data is initialized later, we don't need to initialize
> the data member of the template variable unix_table.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/unix/sysctl_net_unix.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
> index 397cffe..1114ccc 100644
> --- a/net/unix/sysctl_net_unix.c
> +++ b/net/unix/sysctl_net_unix.c
> @@ -15,10 +15,9 @@
>
> #include <net/af_unix.h>
>
> -static ctl_table unix_table[] = {
> +const static ctl_table unix_table[] = {
Typical convention is "static const" rather than "const static"
git grep 'const static' | wc -l => 5
git grep 'static const' | wc -l => 18589
--
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Changli Gao @ 2010-10-19 6:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <1287467263.2775.2.camel@edumazet-laptop>
On Tue, Oct 19, 2010 at 1:47 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 19 octobre 2010 à 13:24 +0800, Changli Gao a écrit :
>> And since ctl_table.data is initialized later, we don't need to initialize
>> the data member of the template variable unix_table.
>>
>
> The init cost is nothing, since its a data blob that must be there
> anyway.
Yes. I have tried to avoid global variable unix_table and unix_path,
then I got a bigger kernel image, so I gave it up.
>
> We could even avoid the kmemdup() if CONFIG_NET_NS is not set
>
>
It is a good idea. We can check if the NS is init_net before kmalloc and kfree.
I'll send a update patch later. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* RE: [PATCH net-next] netxen: make local function static.
From: Amit Salecha @ 2010-10-19 6:36 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, Narender Kumar,
Rajesh Borundia
Cc: netdev@vger.kernel.org
In-Reply-To: <20101018204010.1dc01291@nehalam>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Tuesday, October 19, 2010 9:10 AM
> To: Amit Salecha; David S. Miller; Narender Kumar; Rajesh Borundia
> Cc: netdev@vger.kernel.org
> Subject: [PATCH net-next] netxen: make local function static.
>
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> drivers/net/netxen/netxen_nic.h | 18 +-----------------
> drivers/net/netxen/netxen_nic_hw.c | 29 +++++++++++---------------
> ---
> drivers/net/netxen/netxen_nic_main.c | 6 ++++--
> 3 files changed, 16 insertions(+), 37 deletions(-)
>
Thanks for this. I always run sparse tool before submitting patches, but I never got warning about this.
-Amit
^ permalink raw reply
* Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic
From: emin ak @ 2010-10-19 6:44 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon,
Anton Vorontsov
In-Reply-To: <20101016194815.GA1894@del.dom.local>
Hi Jarek;
After 5 days and more then 20 billion packets passed without crash, it
seems that this patch is working for me, at least for crash type 2.
(For type 1, it only occured once and I can never reproduce this
again, but still trying. I think with this patch is also lowers the
risk for type 1.
For adding a new bug entry for skb_over_panic, before that I think I
must find a reliable way to make this type of crash reproducable,
otherwise I don't know how to test it if it solved or not.
Lastly, thanks a lot for your valuable help to overcome this problem
and also is there anything that I can do for testing / commiting this
patch to mainline?
Thanks
Emin
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Arnd Bergmann @ 2010-10-19 7:26 UTC (permalink / raw)
To: Dave Airlie
Cc: Theodore Kilgore, Steven Rostedt, Greg KH, codalist, autofs,
Samuel Ortiz, Jan Kara, Mikulas Patocka, Jan Harkes, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, ksummit-2010-discuss, Petr Vandrovec,
Arnaldo Carvalho de Melo, linux-fsdevel, Evgeniy Dushistov,
Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <AANLkTi=oAeuz8ZxcOMpf=3MVY=WMt0BwHiGCUxO7OAEV@mail.gmail.com>
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros offer a non-smp kernel as an installation option in case the user
> > needs it? So in reality how big a problem is this?
>
> Not anymore, which is my old point of making a fuss. Nowadays in the
> modern distro world, we supply a single kernel that can at runtime
> decide if its running on SMP or UP and rewrite the text section
> appropriately with locks etc. Its like magic, and something like
> marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> what you want now is a runtime warning if someone tries to hotplug a
> CPU with a known iffy driver loaded or if someone tries to load the
> driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
^ permalink raw reply
* Re: tbf/htb qdisc limitations
From: Bill Fink @ 2010-10-19 7:37 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Eric Dumazet, Rick Jones, Steven Brudenell, netdev
In-Reply-To: <20101017203618.GA1889@del.dom.local>
On Sun, 17 Oct 2010, Jarek Poplawski wrote:
> On Sat, Oct 16, 2010 at 09:24:34PM -0400, Bill Fink wrote:
> > On Sat, 16 Oct 2010, Jarek Poplawski wrote:
> ...
> > > http://code.google.com/p/pspacer/wiki/HTBon10GbE
> > >
> > > If it doesn't help reconsider hfsc.
> >
> > Thanks for the link. From his results, it appears you can
> > get better accuracy by keeping TSO/GSO enabled and upping
> > the tc mtu parameter to 64000. I will have to try that out.
>
> Sure, but you have to remember that scheduler doesn't know real packet
> sizes and rate tables are less accurate especially for smaller packets,
> so it depends on conditions.
On my testing on the real data path, TSO/GSO enabled did seem
to give more accurate results for a single stream. But when
I tried multiple 10-GigE paths simultaneously, each with a
single stream across it, non-TSO/GSO seemed to fare better
overall.
-Bill
^ permalink raw reply
* RE: [PATCH net-next-2.6] mlx4: make functions local and remove dead code.
From: Yevgeny Petrilin @ 2010-10-19 7:37 UTC (permalink / raw)
To: Stephen Hemminger, David Miller; +Cc: netdev@vger.kernel.org, Eli Cohen
In-Reply-To: <20101018083059.164fc8d8@nehalam>
>
> There is a whole section of code in this driver related to vlan tables
> which is not accessed from any kernel code.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
Thanks for sending this,
There are patches under review at the moment (RDMA over Ethernet) that use this code:
http://www.spinics.net/lists/linux-rdma/msg05512.html, which will be broken if the VLAN tables code is removed.
Thanks,
Yevgeny
^ permalink raw reply
* [PATCH net-next-2.6 v2] can: tscan1: add driver for TS-CAN1 boards
From: Andre B. Oliveira @ 2010-10-19 7:47 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w
Add driver for Technologic Systems TS-CAN1 PC104 peripheral boards.
Signed-off-by: Andre B. Oliveira <anbadeol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/can/sja1000/Kconfig | 12 ++
drivers/net/can/sja1000/Makefile | 1 +
drivers/net/can/sja1000/tscan1.c | 216 ++++++++++++++++++++++++++++++++++++++
3 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/can/sja1000/tscan1.c
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index ae3505a..6fdc031 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -58,4 +58,16 @@ config CAN_PLX_PCI
- esd CAN-PCIe/2000
- Marathon CAN-bus-PCI card (http://www.marathon.ru/)
- TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/)
+
+config CAN_TSCAN1
+ tristate "TS-CAN1 PC104 boards"
+ depends on ISA
+ help
+ This driver is for Technologic Systems' TSCAN-1 PC104 boards.
+ http://www.embeddedarm.com/products/board-detail.php?product=TS-CAN1
+ The driver supports multiple boards and automatically configures them:
+ PLD IO base addresses are read from jumpers JP1 and JP2,
+ IRQ numbers are read from jumpers JP4 and JP5,
+ SJA1000 IO base addresses are chosen heuristically (first that works).
+
endif
diff --git a/drivers/net/can/sja1000/Makefile b/drivers/net/can/sja1000/Makefile
index ce92455..2c591eb 100644
--- a/drivers/net/can/sja1000/Makefile
+++ b/drivers/net/can/sja1000/Makefile
@@ -9,5 +9,6 @@ obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
obj-$(CONFIG_CAN_PLX_PCI) += plx_pci.o
+obj-$(CONFIG_CAN_TSCAN1) += tscan1.o
ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
diff --git a/drivers/net/can/sja1000/tscan1.c b/drivers/net/can/sja1000/tscan1.c
new file mode 100644
index 0000000..9756099
--- /dev/null
+++ b/drivers/net/can/sja1000/tscan1.c
@@ -0,0 +1,216 @@
+/*
+ * tscan1.c: driver for Technologic Systems TS-CAN1 PC104 boards
+ *
+ * Copyright 2010 Andre B. Oliveira
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * References:
+ * - Getting started with TS-CAN1, Technologic Systems, Jun 2009
+ * http://www.embeddedarm.com/documentation/ts-can1-manual.pdf
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/isa.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include "sja1000.h"
+
+MODULE_DESCRIPTION("Driver for Technologic Systems TS-CAN1 PC104 boards");
+MODULE_AUTHOR("Andre B. Oliveira <anbadeol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
+MODULE_LICENSE("GPL");
+
+/* Maximum number of boards (one in each JP1:JP2 setting of IO address) */
+#define TSCAN1_MAXDEV 4
+
+/* PLD registers address offsets */
+#define TSCAN1_ID1 0
+#define TSCAN1_ID2 1
+#define TSCAN1_VERSION 2
+#define TSCAN1_LED 3
+#define TSCAN1_PAGE 4
+#define TSCAN1_MODE 5
+#define TSCAN1_JUMPERS 6
+
+/* PLD board identifier registers magic values */
+#define TSCAN1_ID1_VALUE 0xf6
+#define TSCAN1_ID2_VALUE 0xb9
+
+/* PLD mode register SJA1000 IO enable bit */
+#define TSCAN1_MODE_ENABLE 0x40
+
+/* PLD jumpers register bits */
+#define TSCAN1_JP4 0x10
+#define TSCAN1_JP5 0x20
+
+/* PLD IO base addresses start */
+#define TSCAN1_PLD_ADDRESS 0x150
+
+/* PLD register space size */
+#define TSCAN1_PLD_SIZE 8
+
+/* SJA1000 register space size */
+#define TSCAN1_SJA1000_SIZE 32
+
+/* SJA1000 crystal frequency (16MHz) */
+#define TSCAN1_SJA1000_XTAL 16000000
+
+/* SJA1000 IO base addresses */
+static const unsigned short tscan1_sja1000_addresses[] __devinitconst = {
+ 0x100, 0x120, 0x180, 0x1a0, 0x200, 0x240, 0x280, 0x320
+};
+
+/* Read SJA1000 register */
+static u8 tscan1_read(const struct sja1000_priv *priv, int reg)
+{
+ return inb((unsigned long)priv->reg_base + reg);
+}
+
+/* Write SJA1000 register */
+static void tscan1_write(const struct sja1000_priv *priv, int reg, u8 val)
+{
+ outb(val, (unsigned long)priv->reg_base + reg);
+}
+
+/* Probe for a TS-CAN1 board with JP2:JP1 jumper setting ID */
+static int __devinit tscan1_probe(struct device *dev, unsigned id)
+{
+ struct net_device *netdev;
+ struct sja1000_priv *priv;
+ unsigned long pld_base, sja1000_base;
+ int irq, i;
+
+ pld_base = TSCAN1_PLD_ADDRESS + id * TSCAN1_PLD_SIZE;
+ if (!request_region(pld_base, TSCAN1_PLD_SIZE, dev_name(dev)))
+ return -EBUSY;
+
+ if (inb(pld_base + TSCAN1_ID1) != TSCAN1_ID1_VALUE ||
+ inb(pld_base + TSCAN1_ID2) != TSCAN1_ID2_VALUE) {
+ release_region(pld_base, TSCAN1_PLD_SIZE);
+ return -ENODEV;
+ }
+
+ switch (inb(pld_base + TSCAN1_JUMPERS) & (TSCAN1_JP4 | TSCAN1_JP5)) {
+ case TSCAN1_JP4:
+ irq = 6;
+ break;
+ case TSCAN1_JP5:
+ irq = 7;
+ break;
+ case TSCAN1_JP4 | TSCAN1_JP5:
+ irq = 5;
+ break;
+ default:
+ dev_err(dev, "invalid JP4:JP5 setting (no IRQ)\n");
+ release_region(pld_base, TSCAN1_PLD_SIZE);
+ return -EINVAL;
+ }
+
+ netdev = alloc_sja1000dev(0);
+ if (!netdev) {
+ release_region(pld_base, TSCAN1_PLD_SIZE);
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(dev, netdev);
+ SET_NETDEV_DEV(netdev, dev);
+
+ netdev->base_addr = pld_base;
+ netdev->irq = irq;
+
+ priv = netdev_priv(netdev);
+ priv->read_reg = tscan1_read;
+ priv->write_reg = tscan1_write;
+ priv->can.clock.freq = TSCAN1_SJA1000_XTAL / 2;
+ priv->cdr = CDR_CBP | CDR_CLK_OFF;
+ priv->ocr = OCR_TX0_PUSHPULL;
+
+ /* Select the first SJA1000 IO address that is free and that works */
+ for (i = 0; i < ARRAY_SIZE(tscan1_sja1000_addresses); i++) {
+ sja1000_base = tscan1_sja1000_addresses[i];
+ if (!request_region(sja1000_base, TSCAN1_SJA1000_SIZE,
+ dev_name(dev)))
+ continue;
+
+ /* Set SJA1000 IO base address and enable it */
+ outb(TSCAN1_MODE_ENABLE | i, pld_base + TSCAN1_MODE);
+
+ priv->reg_base = (void __iomem *)sja1000_base;
+ if (!register_sja1000dev(netdev)) {
+ /* SJA1000 probe succeeded; turn LED off and return */
+ outb(0, pld_base + TSCAN1_LED);
+ netdev_info(netdev, "TS-CAN1 at 0x%lx 0x%lx irq %d\n",
+ pld_base, sja1000_base, irq);
+ return 0;
+ }
+
+ /* SJA1000 probe failed; release and try next address */
+ outb(0, pld_base + TSCAN1_MODE);
+ release_region(sja1000_base, TSCAN1_SJA1000_SIZE);
+ }
+
+ dev_err(dev, "failed to assign SJA1000 IO address\n");
+ dev_set_drvdata(dev, NULL);
+ free_sja1000dev(netdev);
+ release_region(pld_base, TSCAN1_PLD_SIZE);
+ return -ENXIO;
+}
+
+static int __devexit tscan1_remove(struct device *dev, unsigned id /*unused*/)
+{
+ struct net_device *netdev;
+ struct sja1000_priv *priv;
+ unsigned long pld_base, sja1000_base;
+
+ netdev = dev_get_drvdata(dev);
+ unregister_sja1000dev(netdev);
+ dev_set_drvdata(dev, NULL);
+
+ priv = netdev_priv(netdev);
+ pld_base = netdev->base_addr;
+ sja1000_base = (unsigned long)priv->reg_base;
+
+ outb(0, pld_base + TSCAN1_MODE); /* disable SJA1000 IO space */
+
+ release_region(sja1000_base, TSCAN1_SJA1000_SIZE);
+ release_region(pld_base, TSCAN1_PLD_SIZE);
+
+ free_sja1000dev(netdev);
+
+ return 0;
+}
+
+static struct isa_driver tscan1_isa_driver = {
+ .probe = tscan1_probe,
+ .remove = __devexit_p(tscan1_remove),
+ .driver = {
+ .name = "tscan1",
+ },
+};
+
+static int __init tscan1_init(void)
+{
+ return isa_register_driver(&tscan1_isa_driver, TSCAN1_MAXDEV);
+}
+module_init(tscan1_init);
+
+static void __exit tscan1_exit(void)
+{
+ isa_unregister_driver(&tscan1_isa_driver);
+}
+module_exit(tscan1_exit);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v2] can: tscan1: add driver for TS-CAN1 boards
From: Wolfgang Grandegger @ 2010-10-19 8:05 UTC (permalink / raw)
To: Andre B. Oliveira
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1287474447-2049-1-git-send-email-anbadeol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 10/19/2010 09:47 AM, Andre B. Oliveira wrote:
> Add driver for Technologic Systems TS-CAN1 PC104 peripheral boards.
>
> Signed-off-by: Andre B. Oliveira <anbadeol-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks for your contribution.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] bonding: various fixes for bonding, netpoll & netconsole (v3)
From: David Miller @ 2010-10-19 8:06 UTC (permalink / raw)
To: amwang; +Cc: nhorman, netdev, bonding-devel, fubar, andy
In-Reply-To: <4CBD2AE7.9010302@redhat.com>
From: Cong Wang <amwang@redhat.com>
Date: Tue, 19 Oct 2010 13:21:43 +0800
> Which tree do you apply this patchset to? I checked both net-2.6
> and net-next-2.6, neither of them has these patches.
net-next-2.6, but I didn't push it out until just now so that
I could do build testing first...
^ permalink raw reply
* Re: [PATCH 2/3 v2] net: cleanups in RX queue allocation
From: Eric Dumazet @ 2010-10-19 8:13 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, bhutchings
In-Reply-To: <alpine.DEB.1.00.1010182056010.6676@pokey.mtv.corp.google.com>
Le lundi 18 octobre 2010 à 21:00 -0700, Tom Herbert a écrit :
> Clean up in RX queue allocation. In netif_set_real_num_rx_queues
> return error on attempt to set zero queues, or requested number is
> greater than number of allocated queues. In netif_alloc_rx_queues,
> do BUG_ON if queue_count is zero.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3 v2] net: allocate tx queues in register_netdevice
From: Eric Dumazet @ 2010-10-19 8:13 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, bhutchings
In-Reply-To: <alpine.DEB.1.00.1010182100180.6676@pokey.mtv.corp.google.com>
Le lundi 18 octobre 2010 à 21:04 -0700, Tom Herbert a écrit :
> This patch introduces netif_alloc_netdev_queues which is called from
> register_device instead of alloc_netdev_mq. This makes TX queue
> allocation symmetric with RX allocation. Also, queue locks allocation
> is done in netdev_init_one_queue. Change set_real_num_tx_queues to
> fail if requested number < 1 or greater than number of allocated
> queues.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 4 +-
> net/core/dev.c | 106 ++++++++++++++++++++++----------------------
> 2 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 14fbb04..880d565 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1696,8 +1696,8 @@ static inline int netif_is_multiqueue(const struct net_device *dev)
> return dev->num_tx_queues > 1;
> }
>
> -extern void netif_set_real_num_tx_queues(struct net_device *dev,
> - unsigned int txq);
> +extern int netif_set_real_num_tx_queues(struct net_device *dev,
> + unsigned int txq);
>
> #ifdef CONFIG_RPS
> extern int netif_set_real_num_rx_queues(struct net_device *dev,
> diff --git a/net/core/dev.c b/net/core/dev.c
> index d33adec..7ae5c7e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1553,18 +1553,20 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
> * Routine to help set real_num_tx_queues. To avoid skbs mapped to queues
> * greater then real_num_tx_queues stale skbs on the qdisc must be flushed.
> */
> -void netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
> +int netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
> {
> - unsigned int real_num = dev->real_num_tx_queues;
> + if (txq < 1 || txq > dev->num_tx_queues)
> + return -EINVAL;
>
> - if (unlikely(txq > dev->num_tx_queues))
> - ;
> - else if (txq > real_num)
> - dev->real_num_tx_queues = txq;
> - else if (txq < real_num) {
> - dev->real_num_tx_queues = txq;
> - qdisc_reset_all_tx_gt(dev, txq);
> + if (dev->reg_state == NETREG_REGISTERED) {
> + ASSERT_RTNL();
> +
> + if (txq < dev->real_num_tx_queues)
> + qdisc_reset_all_tx_gt(dev, txq);
> }
> +
> + dev->real_num_tx_queues = txq;
> + return 0;
> }
> EXPORT_SYMBOL(netif_set_real_num_tx_queues);
>
> @@ -4928,20 +4930,6 @@ static void rollback_registered(struct net_device *dev)
> rollback_registered_many(&single);
> }
>
> -static void __netdev_init_queue_locks_one(struct net_device *dev,
> - struct netdev_queue *dev_queue,
> - void *_unused)
> -{
> - spin_lock_init(&dev_queue->_xmit_lock);
> - netdev_set_xmit_lockdep_class(&dev_queue->_xmit_lock, dev->type);
> - dev_queue->xmit_lock_owner = -1;
> -}
> -
> -static void netdev_init_queue_locks(struct net_device *dev)
> -{
> - netdev_for_each_tx_queue(dev, __netdev_init_queue_locks_one, NULL);
> -}
> -
> unsigned long netdev_fix_features(unsigned long features, const char *name)
> {
> /* Fix illegal SG+CSUM combinations. */
> @@ -5034,6 +5022,41 @@ static int netif_alloc_rx_queues(struct net_device *dev)
> return 0;
> }
>
> +static int netif_alloc_netdev_queues(struct net_device *dev)
> +{
> + unsigned int count = dev->num_tx_queues;
> + struct netdev_queue *tx;
> +
> + BUG_ON(count < 1);
> +
> + tx = kcalloc(count, sizeof(struct netdev_queue), GFP_KERNEL);
> + if (!tx) {
> + pr_err("netdev: Unable to allocate %u tx queues.\n",
> + count);
> + return -ENOMEM;
One extra tab before the return
Other than that, patch seems fine to me, thanks !
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next] bnx2: Increase max rx ring size from 1K to 2K
From: David Miller @ 2010-10-19 8:14 UTC (permalink / raw)
To: mchan; +Cc: andy, jfeeney, netdev
In-Reply-To: <1287448254-14173-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Mon, 18 Oct 2010 17:30:54 -0700
> A number of customers are reporting packet loss under certain workloads
> (e.g. heavy bursts of small packets) with flow control disabled. A larger
> rx ring helps to prevent these losses.
>
> No change in default rx ring size and memory consumption.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: John Feeney <jfeeney@redhat.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
I don't see how it's any better to queue things more deeply in
hardware, compared to simply using hardware flow control since that's
what it's for and makes the queuing happen in the networking stack of
the sender, in software, which in the end performs better and gives
better feedback to the source of the data.
These huge RX queue sizes are absolutely rediculious, and I've
complained about this before.
And instead of seeing less of this, I keep seeing more of this stuff.
Please exert some pushback on these folks who are doing such insane
things.
Thanks.
^ permalink raw reply
* Re: Linux 2.6.35/TIPC 2.0 ABI breaking changes
From: David Miller @ 2010-10-19 8:16 UTC (permalink / raw)
To: luca
Cc: nhorman, paul.gortmaker, jon.maloy, netdev, linux-kernel,
tipc-discussion
In-Reply-To: <20101019021657.GZ8781@llucax.com.ar>
From: Leandro Lucarella <luca@llucax.com.ar>
Date: Mon, 18 Oct 2010 23:16:57 -0300
>
> The problem is not between the tipc stacks in different hosts, is
> between the tipc stack and the applications using it (well, maybe
> there is a problem somewhere else too).
>
> This was a deliberate API change, not a subtle bug...
Neil et al., if these packets live only between the kernel stack
and the userspace API layer, we should not be byte-swapping this
stuff and we need to fix this fast.
Thanks.
^ permalink raw reply
* Re: [patch v4.1] ipvs: IPv6 tunnel mode
From: Patrick McHardy @ 2010-10-19 8:40 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Julian Anastasov, Julius Volz,
Wensong Zhang, Hans Schillström
In-Reply-To: <20101016075837.GB2027@verge.net.au>
Am 16.10.2010 09:58, schrieb Simon Horman:
> From: Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> ipvs: IPv6 tunnel mode
>
> IPv6 encapsulation uses a bad source address for the tunnel.
> i.e. VIP will be used as local-addr and encap. dst addr.
> Decapsulation will not accept this.
>
> Example
> LVS (eth1 2003::2:0:1/96, VIP 2003::2:0:100)
> (eth0 2003::1:0:1/96)
> RS (ethX 2003::1:0:5/96)
>
> tcpdump
> 2003::2:0:100 > 2003::1:0:5:
> IP6 (hlim 63, next-header TCP (6) payload length: 40)
> 2003::3:0:10.50991 > 2003::2:0:100.http: Flags [S], cksum 0x7312
> (correct), seq 3006460279, win 5760, options [mss 1440,sackOK,TS val
> 1904932 ecr 0,nop,wscale 3], length 0
>
> In Linux IPv6 impl. you can't have a tunnel with an any cast address
> receiving packets (I have not tried to interpret RFC 2473)
> To have receive capabilities the tunnel must have:
> - Local address set as multicast addr or an unicast addr
> - Remote address set as an unicast addr.
> - Loop back addres or Link local address are not allowed.
>
> This causes us to setup a tunnel in the Real Server with the
> LVS as the remote address, here you can't use the VIP address since it's
> used inside the tunnel.
>
> Solution
> Use outgoing interface IPv6 address (match against the destination).
> i.e. use ip6_route_output() to look up the route cache and
> then use ipv6_dev_get_saddr(...) to set the source address of the
> encapsulated packet.
>
> Additionally, cache the results in new destination
> fields: dst_cookie and dst_saddr and properly check the
> returned dst from ip6_route_output. We now add xfrm_lookup
> call only for the tunneling method where the source address
> is a local one.
>
> Signed-off-by:Hans Schillstrom <hans.schillstrom@ericsson.com>
>
> ---
>
> Original patch by Hans Schillstrom.
> Check dst state and cache results for IPv6 by Julian Anastasov.
> Subsequent revisions made by Hans Schillstrom:
>
> * v1
>
> This is Julian's patch with a slightly edited version of the description
> from Hans's original patch.
>
> * v2
>
> Updated changelog as per commends from Julian
>
> * v3
>
> Flowi dest address used as destination instead of rt6_info in
> +ip_vs_tunnel_xmit_v6()
> rt6_info somtimes contains a netw address insted of a tunnel
>
> * v4
>
> Update destination as recommended from Julian
> i.e. use &cp->daddr.in6
>
> * v4.1 Simon Horman
> Fix patch corruption
>
> Patrick, please consider this for nf-next-2.6
Applied, thanks.
^ permalink raw reply
* Re: Nested GRE locking bug
From: David Miller @ 2010-10-19 8:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: ben, netdev, beatrice.barbe, 599816
In-Reply-To: <1287029519.2649.108.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Oct 2010 06:11:59 +0200
> net-next-2.6 contains a fix for this, adding the perc_cpu
> xmit_recursion limit. We might push it to net-2.6
We need to think a bit more about this.
We are essentially now saying that one can only configure
tunnels 3 levels deep, and no more.
I can guarentee you someone out there uses at least 4,
perhaps more.
And those people will be broken by the new limit.
So putting this into net-2.6 with such a low limit will
be quite dangerous.
^ 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