* [PATCH net-next-2.6 13/17] myri10ge: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Andrew Gallatin, Brice Goglin
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/myri10ge/myri10ge.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 4f3a3c0..3ad1a21 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -990,7 +990,7 @@ static int myri10ge_reset(struct myri10ge_priv *mgp)
* RX queues, so if we get an error, first retry using a
* single TX queue before giving up */
if (status != 0 && mgp->dev->real_num_tx_queues > 1) {
- mgp->dev->real_num_tx_queues = 1;
+ netif_set_real_num_tx_queues(mgp->dev, 1);
cmd.data0 = mgp->num_slices;
cmd.data1 = MXGEFW_SLICE_INTR_MODE_ONE_PER_SLICE;
status = myri10ge_send_cmd(mgp,
@@ -3923,7 +3923,8 @@ static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
dev_err(&pdev->dev, "failed to alloc slice state\n");
goto abort_with_firmware;
}
- netdev->real_num_tx_queues = mgp->num_slices;
+ netif_set_real_num_tx_queues(netdev, mgp->num_slices);
+ netif_set_real_num_rx_queues(netdev, mgp->num_slices);
status = myri10ge_reset(mgp);
if (status != 0) {
dev_err(&pdev->dev, "failed reset\n");
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 12/17] mv643xx_eth: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Lennert Buytenhek
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/mv643xx_eth.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 2d488ab..dd2b6a7 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2901,7 +2901,8 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
mp->dev = dev;
set_params(mp, pd);
- dev->real_num_tx_queues = mp->txq_count;
+ netif_set_real_num_tx_queues(dev, mp->txq_count);
+ netif_set_real_num_rx_queues(dev, mp->rxq_count);
if (pd->phy_addr != MV643XX_ETH_PHY_NONE)
mp->phy = phy_scan(mp, pd->phy_addr);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 11/17] mlx4_en: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Yevgeny Petrilin
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/mlx4/en_netdev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/mlx4/en_netdev.c b/drivers/net/mlx4/en_netdev.c
index 411bda5..79478bd 100644
--- a/drivers/net/mlx4/en_netdev.c
+++ b/drivers/net/mlx4/en_netdev.c
@@ -1025,7 +1025,8 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
*/
dev->netdev_ops = &mlx4_netdev_ops;
dev->watchdog_timeo = MLX4_EN_WATCHDOG_TIMEOUT;
- dev->real_num_tx_queues = MLX4_EN_NUM_TX_RINGS;
+ netif_set_real_num_tx_queues(dev, priv->tx_ring_num);
+ netif_set_real_num_rx_queues(dev, priv->rx_ring_num);
SET_ETHTOOL_OPS(dev, &mlx4_en_ethtool_ops);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 10/17] ixgbe: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:28 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-net-drivers, PJ Waskiewicz, John Ronciak,
e1000-devel, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Alex Duyck
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/ixgbe/ixgbe_main.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 4e0ce91..c35185c 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -4088,7 +4088,7 @@ static inline bool ixgbe_set_sriov_queues(struct ixgbe_adapter *adapter)
* fallthrough conditions.
*
**/
-static void ixgbe_set_num_queues(struct ixgbe_adapter *adapter)
+static int ixgbe_set_num_queues(struct ixgbe_adapter *adapter)
{
/* Start with base case */
adapter->num_rx_queues = 1;
@@ -4097,7 +4097,7 @@ static void ixgbe_set_num_queues(struct ixgbe_adapter *adapter)
adapter->num_rx_queues_per_pool = 1;
if (ixgbe_set_sriov_queues(adapter))
- return;
+ goto done;
#ifdef IXGBE_FCOE
if (ixgbe_set_fcoe_queues(adapter))
@@ -4120,8 +4120,10 @@ static void ixgbe_set_num_queues(struct ixgbe_adapter *adapter)
adapter->num_tx_queues = 1;
done:
- /* Notify the stack of the (possibly) reduced Tx Queue count. */
+ /* Notify the stack of the (possibly) reduced queue counts. */
netif_set_real_num_tx_queues(adapter->netdev, adapter->num_tx_queues);
+ return netif_set_real_num_rx_queues(adapter->netdev,
+ adapter->num_rx_queues);
}
static void ixgbe_acquire_msix_vectors(struct ixgbe_adapter *adapter,
@@ -4550,7 +4552,9 @@ static int ixgbe_set_interrupt_capability(struct ixgbe_adapter *adapter)
if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
ixgbe_disable_sriov(adapter);
- ixgbe_set_num_queues(adapter);
+ err = ixgbe_set_num_queues(adapter);
+ if (err)
+ return err;
err = pci_enable_msi(adapter->pdev);
if (!err) {
@@ -4675,7 +4679,9 @@ int ixgbe_init_interrupt_scheme(struct ixgbe_adapter *adapter)
int err;
/* Number of supported queues */
- ixgbe_set_num_queues(adapter);
+ err = ixgbe_set_num_queues(adapter);
+ if (err)
+ return err;
err = ixgbe_set_interrupt_capability(adapter);
if (err) {
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 09/17] igb: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:28 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-net-drivers, e1000-devel, Jeff Kirsher,
Jesse Brandeburg, Bruce Allan, Alex Duyck, PJ Waskiewicz,
John Ronciak
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/igb/igb_main.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 0394ca9..55edcb7 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -988,7 +988,7 @@ static void igb_clear_interrupt_scheme(struct igb_adapter *adapter)
* Attempt to configure interrupts using the best available
* capabilities of the hardware and kernel.
**/
-static void igb_set_interrupt_capability(struct igb_adapter *adapter)
+static int igb_set_interrupt_capability(struct igb_adapter *adapter)
{
int err;
int numvecs, i;
@@ -1054,8 +1054,10 @@ msi_only:
if (!pci_enable_msi(adapter->pdev))
adapter->flags |= IGB_FLAG_HAS_MSI;
out:
- /* Notify the stack of the (possibly) reduced Tx Queue count. */
- adapter->netdev->real_num_tx_queues = adapter->num_tx_queues;
+ /* Notify the stack of the (possibly) reduced queue counts. */
+ netif_set_real_num_tx_queues(adapter->netdev, adapter->num_tx_queues);
+ return netif_set_real_num_rx_queues(adapter->netdev,
+ adapter->num_rx_queues);
}
/**
@@ -1154,7 +1156,9 @@ static int igb_init_interrupt_scheme(struct igb_adapter *adapter)
struct pci_dev *pdev = adapter->pdev;
int err;
- igb_set_interrupt_capability(adapter);
+ err = igb_set_interrupt_capability(adapter);
+ if (err)
+ return err;
err = igb_alloc_q_vectors(adapter);
if (err) {
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 08/17] gianfar: Use netif_set_real_num_rx_queues()
From: Ben Hutchings @ 2010-09-27 18:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Anton Vorontsov
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Do not set num_tx_queues or real_num_tx_queues, since
alloc_etherdev_mq() does that.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/gianfar.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f30adbf..6180089 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -654,9 +654,8 @@ static int gfar_of_init(struct platform_device *ofdev, struct net_device **pdev)
priv->node = ofdev->dev.of_node;
priv->ndev = dev;
- dev->num_tx_queues = num_tx_qs;
- dev->real_num_tx_queues = num_tx_qs;
priv->num_tx_queues = num_tx_qs;
+ netif_set_real_num_rx_queues(dev, num_rx_qs);
priv->num_rx_queues = num_rx_qs;
priv->num_grps = 0x0;
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 07/17] cxgb4vf: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Casey Leedom
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index 7b6d07f..555ecc5 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -748,7 +748,10 @@ static int cxgb4vf_open(struct net_device *dev)
/*
* Note that this interface is up and start everything up ...
*/
- dev->real_num_tx_queues = pi->nqsets;
+ netif_set_real_num_tx_queues(dev, pi->nqsets);
+ err = netif_set_real_num_rx_queues(dev, pi->nqsets);
+ if (err)
+ return err;
set_bit(pi->port_id, &adapter->open_device_map);
link_start(dev);
netif_tx_start_all_queues(dev);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 06/17] cxgb4: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Dimitris Michailidis
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/cxgb4/cxgb4_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 75b9401..4fb08e3 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -2763,7 +2763,10 @@ static int cxgb_open(struct net_device *dev)
return err;
}
- dev->real_num_tx_queues = pi->nqsets;
+ netif_set_real_num_tx_queues(dev, pi->nqsets);
+ err = netif_set_real_num_rx_queues(dev, pi->nqsets);
+ if (err)
+ return err;
err = link_start(dev);
if (!err)
netif_tx_start_all_queues(dev);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: John W. Linville @ 2010-09-27 18:25 UTC (permalink / raw)
To: David Miller; +Cc: ohad, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100927.111818.149846920.davem@davemloft.net>
On Mon, Sep 27, 2010 at 11:18:18AM -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Mon, 27 Sep 2010 14:04:12 -0400
>
> > Subject: [PATCH] wl12xx: fix separate-object-folder builds
> >
> > Make this go away (happens when building with a separate object
> > directory):
> >
> > Assembler messages:
> > Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> BTW, if this fuglet going to work if the driver is built modular?
>
> The idea of this things seems to be to allow arch platform code to call
> into it to set things. Such calls from arch platform code are going
> to be "obj-y"
>
> So if this is built into the modular driver, I can't see how it
> can work.
Dave is right -- these Kconfig dependencies (or lack thereof) seem
to be wrong. Seems like the OMAP code needs to select the option
for this code?
John
--
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
* [PATCH net-next-2.6 05/17] cxgb3: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Divy Le Ray
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/cxgb3/cxgb3_main.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index f9eede0..a04ce6a 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -1399,7 +1399,10 @@ static int cxgb_open(struct net_device *dev)
"Could not initialize offload capabilities\n");
}
- dev->real_num_tx_queues = pi->nqsets;
+ netif_set_real_num_tx_queues(dev, pi->nqsets);
+ err = netif_set_real_num_rx_queues(dev, pi->nqsets);
+ if (err)
+ return err;
link_start(dev);
t3_port_intr_enable(adapter, pi->port_id);
netif_tx_start_all_queues(dev);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 04/17] bnx2x: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Eilon Greenstein
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index efc7be4..05c05a4 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1207,8 +1207,8 @@ static int bnx2x_set_num_queues(struct bnx2x *bp)
bp->num_queues = 1;
break;
}
- bp->dev->real_num_tx_queues = bp->num_queues;
- return rc;
+ netif_set_real_num_tx_queues(bp->dev, bp->num_queues);
+ return netif_set_real_num_rx_queues(bp->dev, bp->num_queues);
}
static void bnx2x_release_firmware(struct bnx2x *bp)
@@ -1240,6 +1240,8 @@ int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
bp->state = BNX2X_STATE_OPENING_WAIT4_LOAD;
rc = bnx2x_set_num_queues(bp);
+ if (rc)
+ return rc;
if (bnx2x_alloc_mem(bp)) {
bnx2x_free_irq(bp, true);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 03/17] bnx2: Use netif_set_real_num_{rx,tx}_queues()
From: Ben Hutchings @ 2010-09-27 18:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Michael Chan
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/bnx2.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 3d1a5da..b10be27 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -6202,7 +6202,7 @@ bnx2_enable_msix(struct bnx2 *bp, int msix_vecs)
}
}
-static void
+static int
bnx2_setup_int_mode(struct bnx2 *bp, int dis_msi)
{
int cpus = num_online_cpus();
@@ -6231,9 +6231,10 @@ bnx2_setup_int_mode(struct bnx2 *bp, int dis_msi)
}
bp->num_tx_rings = rounddown_pow_of_two(bp->irq_nvecs);
- bp->dev->real_num_tx_queues = bp->num_tx_rings;
+ netif_set_real_num_tx_queues(bp->dev, bp->num_tx_rings);
bp->num_rx_rings = bp->irq_nvecs;
+ return netif_set_real_num_rx_queues(bp->dev, bp->num_rx_rings);
}
/* Called with rtnl_lock */
@@ -6248,7 +6249,9 @@ bnx2_open(struct net_device *dev)
bnx2_set_power_state(bp, PCI_D0);
bnx2_disable_int(bp);
- bnx2_setup_int_mode(bp, disable_msi);
+ rc = bnx2_setup_int_mode(bp, disable_msi);
+ if (rc)
+ goto open_err;
bnx2_init_napi(bp);
bnx2_napi_enable(bp);
rc = bnx2_alloc_mem(bp);
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 02/17] net: Add netif_copy_real_num_queues() for use by virtual net drivers
From: Ben Hutchings @ 2010-09-27 18:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
This sets the active numbers of queues on a net device to match another.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/netdevice.h | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cf3d5a3..7fd39b3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1698,6 +1698,18 @@ static inline int netif_set_real_num_rx_queues(struct net_device *dev,
}
#endif
+static inline int netif_copy_real_num_queues(struct net_device *to_dev,
+ const struct net_device *from_dev)
+{
+ netif_set_real_num_tx_queues(to_dev, from_dev->real_num_tx_queues);
+#ifdef CONFIG_RPS
+ return netif_set_real_num_rx_queues(to_dev,
+ from_dev->real_num_rx_queues);
+#else
+ return 0;
+#endif
+}
+
/* Use this variant when it is known for sure that it
* is executing from hardware interrupt context or with hardware interrupts
* disabled.
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 01/17] net: Allow changing number of RX queues after device allocation
From: Ben Hutchings @ 2010-09-27 18:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers, Tom Herbert
In-Reply-To: <1285611791.2263.287.camel@achroite.uk.solarflarecom.com>
For RPS, we create a kobject for each RX queue based on the number of
queues passed to alloc_netdev_mq(). However, drivers generally do not
determine the numbers of hardware queues to use until much later, so
this usually represents the maximum number the driver may use and not
the actual number in use.
For TX queues, drivers can update the actual number using
netif_set_real_num_tx_queues(). Add a corresponding function for RX
queues, netif_set_real_num_rx_queues().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/netdevice.h | 16 +++++++++++++++-
net/core/dev.c | 45 +++++++++++++++++++++++++++++++++++++++++----
net/core/net-sysfs.c | 34 +++++++++++++++++++---------------
net/core/net-sysfs.h | 4 ++++
4 files changed, 79 insertions(+), 20 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 01bd4c8..cf3d5a3 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -976,8 +976,11 @@ struct net_device {
struct netdev_rx_queue *_rx;
- /* Number of RX queues allocated at alloc_netdev_mq() time */
+ /* Number of RX queues allocated at register_netdev() time */
unsigned int num_rx_queues;
+
+ /* Number of RX queues currently active in device */
+ unsigned int real_num_rx_queues;
#endif
rx_handler_func_t *rx_handler;
@@ -1684,6 +1687,17 @@ static inline int netif_is_multiqueue(const struct net_device *dev)
extern void 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,
+ unsigned int rxq);
+#else
+static inline int netif_set_real_num_rx_queues(struct net_device *dev,
+ unsigned int rxq)
+{
+ return 0;
+}
+#endif
+
/* Use this variant when it is known for sure that it
* is executing from hardware interrupt context or with hardware interrupts
* disabled.
diff --git a/net/core/dev.c b/net/core/dev.c
index 42b200f..48ad47f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1567,6 +1567,41 @@ void netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
}
EXPORT_SYMBOL(netif_set_real_num_tx_queues);
+#ifdef CONFIG_RPS
+/**
+ * netif_set_real_num_rx_queues - set actual number of RX queues used
+ * @dev: Network device
+ * @rxq: Actual number of RX queues
+ *
+ * This must be called either with the rtnl_lock held or before
+ * registration of the net device. Returns 0 on success, or a
+ * negative error code. If called before registration, it also
+ * sets the maximum number of queues, and always succeeds.
+ */
+int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
+{
+ int rc;
+
+ if (dev->reg_state == NETREG_REGISTERED) {
+ ASSERT_RTNL();
+
+ if (rxq > dev->num_rx_queues)
+ return -EINVAL;
+
+ rc = net_rx_queue_update_kobjects(dev, dev->real_num_rx_queues,
+ rxq);
+ if (rc)
+ return rc;
+ } else {
+ dev->num_rx_queues = rxq;
+ }
+
+ dev->real_num_rx_queues = rxq;
+ return 0;
+}
+EXPORT_SYMBOL(netif_set_real_num_rx_queues);
+#endif
+
static inline void __netif_reschedule(struct Qdisc *q)
{
struct softnet_data *sd;
@@ -2352,10 +2387,11 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
if (skb_rx_queue_recorded(skb)) {
u16 index = skb_get_rx_queue(skb);
- if (unlikely(index >= dev->num_rx_queues)) {
- WARN_ONCE(dev->num_rx_queues > 1, "%s received packet "
- "on queue %u, but number of RX queues is %u\n",
- dev->name, index, dev->num_rx_queues);
+ if (unlikely(index >= dev->real_num_rx_queues)) {
+ WARN_ONCE(dev->real_num_rx_queues > 1,
+ "%s received packet on queue %u, but number "
+ "of RX queues is %u\n",
+ dev->name, index, dev->real_num_rx_queues);
goto done;
}
rxqueue = dev->_rx + index;
@@ -5472,6 +5508,7 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
#ifdef CONFIG_RPS
dev->num_rx_queues = queue_count;
+ dev->real_num_rx_queues = queue_count;
#endif
dev->gso_max_size = GSO_MAX_SIZE;
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 76485a3..4791cfc 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -742,34 +742,38 @@ static int rx_queue_add_kobject(struct net_device *net, int index)
return error;
}
-static int rx_queue_register_kobjects(struct net_device *net)
+int
+net_rx_queue_update_kobjects(struct net_device *net, int old_num, int new_num)
{
int i;
int error = 0;
-
- net->queues_kset = kset_create_and_add("queues",
- NULL, &net->dev.kobj);
- if (!net->queues_kset)
- return -ENOMEM;
- for (i = 0; i < net->num_rx_queues; i++) {
+
+ for (i = old_num; i < new_num; i++) {
error = rx_queue_add_kobject(net, i);
- if (error)
+ if (error) {
+ new_num = old_num;
break;
+ }
}
- if (error)
- while (--i >= 0)
- kobject_put(&net->_rx[i].kobj);
+ while (--i >= new_num)
+ kobject_put(&net->_rx[i].kobj);
return error;
}
-static void rx_queue_remove_kobjects(struct net_device *net)
+static int rx_queue_register_kobjects(struct net_device *net)
{
- int i;
+ net->queues_kset = kset_create_and_add("queues",
+ NULL, &net->dev.kobj);
+ if (!net->queues_kset)
+ return -ENOMEM;
+ return net_rx_queue_update_kobjects(net, 0, net->real_num_rx_queues);
+}
- for (i = 0; i < net->num_rx_queues; i++)
- kobject_put(&net->_rx[i].kobj);
+static void rx_queue_remove_kobjects(struct net_device *net)
+{
+ net_rx_queue_update_kobjects(net, net->real_num_rx_queues, 0);
kset_unregister(net->queues_kset);
}
#endif /* CONFIG_RPS */
diff --git a/net/core/net-sysfs.h b/net/core/net-sysfs.h
index 805555e..778e157 100644
--- a/net/core/net-sysfs.h
+++ b/net/core/net-sysfs.h
@@ -4,4 +4,8 @@
int netdev_kobject_init(void);
int netdev_register_kobject(struct net_device *);
void netdev_unregister_kobject(struct net_device *);
+#ifdef CONFIG_RPS
+int net_rx_queue_update_kobjects(struct net_device *, int old_num, int new_num);
+#endif
+
#endif
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* [PATCH net-next-2.6 00/17] netdev: Fix queue count initialisation
From: Ben Hutchings @ 2010-09-27 18:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
This adds the functions:
- netif_set_real_num_rx_queues() - set actual number of RX queues used
- netif_copy_real_num_queues() - copy queue counts from another device
and changes all drivers that currently set
net_device::real_num_tx_queues to use netif_set_real_num_tx_queues()
and/or these functions.
The changes are compile-tested only, except that:
- sfc and 8021q have been briefly tested
- gianfar and mv643xx_eth have not been compiled, since they are
platform-specific
I noticed that the bonding driver sets its numbers of queues without
regard to its slave devices. This makes some sense since a bond device
initially has no slave devices. However, it seems to mean that a bond
device can pass up an skb with an out-of-range queue_index, triggering a
warning in get_rps_cpu().
Ben.
Ben Hutchings (17):
net: Allow changing number of RX queues after device allocation
net: Add netif_copy_real_num_queues() for use by virtual net drivers
bnx2: Use netif_set_real_num_{rx,tx}_queues()
bnx2x: Use netif_set_real_num_{rx,tx}_queues()
cxgb3: Use netif_set_real_num_{rx,tx}_queues()
cxgb4: Use netif_set_real_num_{rx,tx}_queues()
cxgb4vf: Use netif_set_real_num_{rx,tx}_queues()
gianfar: Use netif_set_real_num_rx_queues()
igb: Use netif_set_real_num_{rx,tx}_queues()
ixgbe: Use netif_set_real_num_{rx,tx}_queues()
mlx4_en: Use netif_set_real_num_{rx,tx}_queues()
mv643xx_eth: Use netif_set_real_num_{rx,tx}_queues()
myri10ge: Use netif_set_real_num_{rx,tx}_queues()
niu: Use netif_set_real_num_{rx,tx}_queues()
sfc: Use netif_set_real_num_{rx,tx}_queues()
tg3: Use netif_set_real_num_{rx,tx}_queues()
8021q: Use netif_copy_real_num_queues() to set queue counts
drivers/net/bnx2.c | 9 ++++--
drivers/net/bnx2x/bnx2x_cmn.c | 6 +++-
drivers/net/cxgb3/cxgb3_main.c | 5 +++-
drivers/net/cxgb4/cxgb4_main.c | 5 +++-
drivers/net/cxgb4vf/cxgb4vf_main.c | 5 +++-
drivers/net/gianfar.c | 3 +-
drivers/net/igb/igb_main.c | 12 ++++++---
drivers/net/ixgbe/ixgbe_main.c | 16 ++++++++----
drivers/net/mlx4/en_netdev.c | 3 +-
drivers/net/mv643xx_eth.c | 3 +-
drivers/net/myri10ge/myri10ge.c | 5 ++-
drivers/net/niu.c | 3 +-
drivers/net/sfc/efx.c | 3 +-
drivers/net/tg3.c | 8 ++++-
include/linux/netdevice.h | 28 +++++++++++++++++++++-
net/8021q/vlan.c | 2 +-
net/core/dev.c | 45 ++++++++++++++++++++++++++++++++---
net/core/net-sysfs.c | 34 +++++++++++++++------------
net/core/net-sysfs.h | 4 +++
19 files changed, 151 insertions(+), 48 deletions(-)
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: David Miller @ 2010-09-27 18:18 UTC (permalink / raw)
To: linville; +Cc: ohad, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20100927180412.GD11086@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 27 Sep 2010 14:04:12 -0400
> Subject: [PATCH] wl12xx: fix separate-object-folder builds
>
> Make this go away (happens when building with a separate object
> directory):
>
> Assembler messages:
> Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
BTW, if this fuglet going to work if the driver is built modular?
The idea of this things seems to be to allow arch platform code to call
into it to set things. Such calls from arch platform code are going
to be "obj-y"
So if this is built into the modular driver, I can't see how it
can work.
^ permalink raw reply
* Re: igmp: Allow mininum interval specification for igmp timers.
From: David Stevens @ 2010-09-27 18:16 UTC (permalink / raw)
To: David Miller
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <20100927.105444.214208865.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org wrote on 09/27/2010 10:54:44 AM:
> From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> To: David Stevens/Beaverton/IBM@IBMUS
> Cc: cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, rda-x0S3BwdUo6DQT0dZR+AlfA@public.gmane.org
> Date: 09/27/2010 10:54 AM
> Subject: Re: igmp: Allow mininum interval specification for igmp timers.
> Sent by: netdev-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> From: David Stevens <dlstevens-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 27 Sep 2010 10:41:20 -0700
>
> > I don't know if you saw the more extended discussion we
> > had on this or not, but I think while this would help for IB,
> > it's not appropriate in general. These can in fact be "0" per
> > RFC which is worst case for IB if there is a delay for being
> > able to use the group, and the newer IGMPv3 standard has shortened
> > the max interval from 10sec in v2 to 1 sec.
>
> I did see the extended discussion, and it was interesting :-)
>
> But that mainly focused on the second patch, which I appropriately
> marked as needing changes in patchwork.
OK, I'm not sure I've seen them all; haven't caught up on
e-mail yet.
> This patch on the other hand is attacking a different problem,
> namely avoiding the worst cases caused by the randomization we
> do for the timer.
I think the multiples are to allow for drops and the
randomization is to prevent storms. As far as IGMP is concerned,
it's perfectly fine to send them back-to-back, since drops are
not necessarily time periods of network outage (as with IB) but
rather transient queue overflows where even the short delay of
a "0" timer but still having protocol and packet transmit delay
would be fine.
> With bad luck this thing times out way too fast because the total of
> all of the randomized intervals can end up being very small, and I
> think we should fix that independently of the other issues hit by the
> IB folks.
>
> Don't you agree?
If you mean enforcing a minimum spacing higher than a "0" timer,
I don't know that it's an issue for other network types. According to
IGMPv3, all of them (3 total) on average would be sent in 1 sec, but
it also isn't fatal to drop all of them. To the extent that 1 sec is
"small," it is intentional.
I'll try digging out the particular patch and comment. I'm not
sure many of these tweaks would necessarily hurt other network types
but I think the current code also isn't a problem for anything but IB,
and that issue can be fixed within IB.
+-DLS
--
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] net: Fix IPv6 PMTU disc. w/ asymmetric routes
From: David Miller @ 2010-09-27 18:11 UTC (permalink / raw)
To: maze; +Cc: netdev
In-Reply-To: <AANLkTikPOHy79E1ZG=iJ-rHj0vzS+AY-mGqCEtWoXp2o@mail.gmail.com>
From: Maciej Żenczykowski <maze@google.com>
Date: Mon, 27 Sep 2010 03:10:12 -0700
> FYI, I'm signed up to netdev on my personal account.
You don't need to subscribe in order to post patches to the mailing
list.
^ permalink raw reply
* Re: [PATCH] fix TSO FACK loss marking in tcp_mark_head_lost
From: David Miller @ 2010-09-27 18:11 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: ycheng, netdev
In-Reply-To: <alpine.DEB.2.00.1009271520560.26447@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 27 Sep 2010 15:22:09 +0300 (EEST)
> On Fri, 24 Sep 2010, Yuchung Cheng wrote:
>
>> When TCP uses FACK algorithm to mark lost packets in
>> tcp_mark_head_lost(), if the number of packets in the (TSO) skb is
>> greater than the number of packets that should be marked lost, TCP
>> incorrectly exits the loop and marks no packets lost in the skb. This
>> underestimates tp->lost_out and affects the recovery/retransmission.
>> This patch fargments the skb and marks the correct amount of packets
>> lost.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>> ---
>> net/ipv4/tcp_input.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 1bc87a0..e4f472e 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -2532,7 +2532,8 @@ static void tcp_mark_head_lost(struct sock *sk, int packets)
>> cnt += tcp_skb_pcount(skb);
>>
>> if (cnt > packets) {
>> - if (tcp_is_sack(tp) || (oldcnt >= packets))
>> + if ((tcp_is_sack(tp) && !tcp_is_fack(tp)) ||
>> + (oldcnt >= packets))
>> break;
>>
>> mss = skb_shinfo(skb)->gso_size;
>>
>
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
BTW, the history is that this code was added to fix a bug because
we didn't handle GSO packets at all at one point.
But, conservatively, we didn't do splits here for SACK, and it was
stated in the commit that we would look into it "at some point in the
future" :-)
--------------------
commit c137f3dda04b0aee1bc6889cdc69185f53df8a82
Author: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Date: Mon Apr 7 22:32:38 2008 -0700
[TCP]: Fix NewReno's fast rexmit/recovery problems with GSOed skb
Fixes a long-standing bug which makes NewReno recovery crippled.
With GSO the whole head skb was marked as LOST which is in
violation of NewReno procedure that only wants to mark one packet
and ended up breaking our TCP code by causing counter overflow
because our code was built on top of assumption about valid
NewReno procedure. This manifested as triggering a WARN_ON for
the overflow in a number of places.
It seems relatively safe alternative to just do nothing if
tcp_fragment fails due to oom because another duplicate ACK is
likely to be received soon and the fragmentation will be retried.
Special thanks goes to Soeren Sonnenburg <kernel@nn7.de> who was
lucky enough to be able to reproduce this so that the warning
for the overflow was hit. It's not as easy task as it seems even
if this bug happens quite often because the amount of outstanding
data is pretty significant for the mismarkings to lead to an
overflow.
Because it's very late in 2.6.25-rc cycle (if this even makes in
time), I didn't want to touch anything with SACK enabled here.
Fragmenting might be useful for it as well but it's more or less
a policy decision rather than mandatory fix. Thus there's no need
to rush and we can postpone considering tcp_fragment with SACK
for 2.6.26.
In 2.6.24 and earlier, this very same bug existed but the effect
is slightly different because of a small changes in the if
conditions that fit to the patch's context. With them nothing
got lost marker and thus no retransmissions happened.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
--------------------
To be honest, we should probably just remove the whole tcp_is_sack()
test, rather than special case FACK.
The cost isn't what it was when this code was added. Back then we
didn't have Ilpo's restransmit queue coalescing code, so it would make
retransmit queue packet freeing more expensive. But since the
coalescing code is there now, splitting all the time to record
accurate loss information should be fine.
Ilpo what do you say?
^ permalink raw reply
* Re: [PATCH] 3c59x: fix regression from patch "Add ethtool WOL support"
From: David Miller @ 2010-09-27 18:08 UTC (permalink / raw)
To: JBeulich; +Cc: andrew, netdev
In-Reply-To: <4CA09E2D0200007800019050@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Mon, 27 Sep 2010 12:37:49 +0100
> This patch (commit 690a1f2002a3091bd18a501f46c9530f10481463) added a
> new call site for acpi_set_WOL() without checking that the function is
> actually suitable to be called via
>
> vortex_set_wol+0xcd/0xe0 [3c59x]
> dev_ethtool+0xa5a/0xb70
> dev_ioctl+0x2e0/0x4b0
> T.961+0x49/0x50
> sock_ioctl+0x47/0x290
> do_vfs_ioctl+0x7f/0x340
> sys_ioctl+0x80/0xa0
> system_call_fastpath+0x16/0x1b
>
> i.e. outside of code paths run when the device is not yet enabled or
> already disabled. In particular, putting the device into D3hot is a
> pretty bad idea when it was already brought up.
>
> Furthermore, all prior callers of the function made sure they're
> actually dealing with a PCI device, while the newly added one didn't.
>
> In the same spirit, the .get_wol handler shouldn't indicate support
> for WOL for non-PCI devices.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net tree related)
From: John W. Linville @ 2010-09-27 18:04 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Stephen Rothwell, David Miller, netdev, linux-next, linux-kernel
In-Reply-To: <AANLkTinHk82jM7Ztwb1aB1xb-hSLeg5Hb07mhYCaeszi@mail.gmail.com>
On Mon, Sep 27, 2010 at 05:55:42PM +0200, Ohad Ben-Cohen wrote:
> On Mon, Sep 27, 2010 at 7:44 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Assembler messages:
> > Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> > drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
> >
> > Presumably caused by commit 61ee7007a5d61aa066076da578e8e8084e122d7d
> > ("wl12xx: add platform data passing support").
> >
> > I do my builds with a separate object directory (which may be a reason
> > you don't see this).
>
> Thank you, Stephen.
>
> I have just tried building with a separate object directory, and I was
> then able to reproduce it and fix it with:
>
> From fb0d1dc5ce6c258b3ecb0a8997791a77be3c5307 Mon Sep 17 00:00:00 2001
> From: Ohad Ben-Cohen <ohad@wizery.com>
> Date: Mon, 27 Sep 2010 17:33:57 +0200
> Subject: [PATCH] wl12xx: fix separate-object-folder builds
>
> Make this go away (happens when building with a separate object directory):
>
> Assembler messages:
> Fatal error: can't create
> drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file
> or directory
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function
> 'wl12xx_get_platform_data':
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot
> open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
> drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by
> earlier errors, bailing out
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> ---
> drivers/net/wireless/Makefile | 2 +-
> .../wireless/{wl12xx => }/wl12xx_platform_data.c | 0
> 2 files changed, 1 insertions(+), 1 deletions(-)
> rename drivers/net/wireless/{wl12xx => }/wl12xx_platform_data.c (100%)
>
> diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
> index 85af697..0a64bd5 100644
> --- a/drivers/net/wireless/Makefile
> +++ b/drivers/net/wireless/Makefile
> @@ -51,6 +51,6 @@ obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
>
> obj-$(CONFIG_WL12XX) += wl12xx/
> # small builtin driver bit
> -obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
> +obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
>
> obj-$(CONFIG_IWM) += iwmc3200wifi/
> diff --git a/drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> b/drivers/net/wireless/wl12xx_platform_data.c
> similarity index 100%
> rename from drivers/net/wireless/wl12xx/wl12xx_platform_data.c
> rename to drivers/net/wireless/wl12xx_platform_data.c
I like this version better, since it keeps the platform data with
the rest of the code:
>From f8ac84505927d0a1fd79994cefaad7abf9b2e693 Mon Sep 17 00:00:00 2001
From: John W. Linville <linville@tuxdriver.com>
Date: Mon, 27 Sep 2010 14:00:51 -0400
Subject: [PATCH] wl12xx: fix separate-object-folder builds
Make this go away (happens when building with a separate object
directory):
Assembler messages:
Fatal error: can't create drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.o: No such file or directory
drivers/net/wireless/wl12xx/wl12xx_platform_data.c: In function 'wl12xx_get_platform_data':
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: error: cannot open drivers/net/wireless/wl12xx/.tmp_wl12xx_platform_data.gcno
drivers/net/wireless/wl12xx/wl12xx_platform_data.c:28: confused by earlier errors, bailing out
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
---
drivers/net/wireless/Makefile | 2 --
drivers/net/wireless/wl12xx/Makefile | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/Makefile b/drivers/net/wireless/Makefile
index 85af697..5d4ce4d 100644
--- a/drivers/net/wireless/Makefile
+++ b/drivers/net/wireless/Makefile
@@ -50,7 +50,5 @@ obj-$(CONFIG_ATH_COMMON) += ath/
obj-$(CONFIG_MAC80211_HWSIM) += mac80211_hwsim.o
obj-$(CONFIG_WL12XX) += wl12xx/
-# small builtin driver bit
-obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx/wl12xx_platform_data.o
obj-$(CONFIG_IWM) += iwmc3200wifi/
diff --git a/drivers/net/wireless/wl12xx/Makefile b/drivers/net/wireless/wl12xx/Makefile
index 078b439..0d334d6 100644
--- a/drivers/net/wireless/wl12xx/Makefile
+++ b/drivers/net/wireless/wl12xx/Makefile
@@ -16,3 +16,6 @@ wl1271-$(CONFIG_NL80211_TESTMODE) += wl1271_testmode.o
obj-$(CONFIG_WL1271) += wl1271.o
obj-$(CONFIG_WL1271_SPI) += wl1271_spi.o
obj-$(CONFIG_WL1271_SDIO) += wl1271_sdio.o
+
+# small builtin driver bit
+obj-$(CONFIG_WL12XX_PLATFORM_DATA) += wl12xx_platform_data.o
--
1.7.2.3
--
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 related
* Re: igmp: Allow mininum interval specification for igmp timers.
From: David Miller @ 2010-09-27 17:54 UTC (permalink / raw)
To: dlstevens-r/Jw6+rmf7HQT0dZR+AlfA
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <OF4BA8F9C2.467056E9-ON882577AB.005F4832-882577AB.00612DD6-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
From: David Stevens <dlstevens-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Date: Mon, 27 Sep 2010 10:41:20 -0700
> I don't know if you saw the more extended discussion we
> had on this or not, but I think while this would help for IB,
> it's not appropriate in general. These can in fact be "0" per
> RFC which is worst case for IB if there is a delay for being
> able to use the group, and the newer IGMPv3 standard has shortened
> the max interval from 10sec in v2 to 1 sec.
I did see the extended discussion, and it was interesting :-)
But that mainly focused on the second patch, which I appropriately
marked as needing changes in patchwork.
This patch on the other hand is attacking a different problem,
namely avoiding the worst cases caused by the randomization we
do for the timer.
With bad luck this thing times out way too fast because the total of
all of the randomized intervals can end up being very small, and I
think we should fix that independently of the other issues hit by the
IB folks.
Don't you agree?
--
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: igmp: Allow mininum interval specification for igmp timers.
From: David Stevens @ 2010-09-27 17:41 UTC (permalink / raw)
To: David Miller
Cc: cl-vYTEC60ixJUAvxtiuMwx3w, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netdev-owner-u79uwXL29TY76Z2rM5mHXA, rda-x0S3BwdUo6DQT0dZR+AlfA
In-Reply-To: <20100923.213823.137834706.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote on 09/23/2010 09:38:23 PM:
>
> > IGMP timers sometimes fire too rapidly due to randomization of the
> > intervalsfrom 0 to max_delay in igmp_start_timer().
> ...
> > Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
>
>
> This change seems reasonable to me, what do you think David?
[sorry for the delay -- I was off-line for the last few days]
Dave,
I don't know if you saw the more extended discussion we
had on this or not, but I think while this would help for IB,
it's not appropriate in general. These can in fact be "0" per
RFC which is worst case for IB if there is a delay for being
able to use the group, and the newer IGMPv3 standard has shortened
the max interval from 10sec in v2 to 1 sec.
Fundamentally, the problem is that the device needs to
be able to send on the group immediately for IGMP; that it
can't for IB is the problem, and I think it should be solved
in IB by either queueing packets there or delaying there as
needed before doing the joins.
I don't think tweaking IGMP for this is appropriate at
all, but if done there, it ought to be per-interface so it
doesn't change anything for other network types which don't
have this problem. It should be randomized and not the fixed
delays to prevent storms on a mass start-up, and we also don't
want to be increasing the number of duplicates for other
network types. The default should be 2 reports in randomized
0-10 sec for each for v2, 2 in randomized 0-1 sec for v3.
+-DLS
--
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: l2tpv3 support not yet in iproute2?
From: James Chapman @ 2010-09-27 17:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: jpo234, netdev, Stephen Hemminger
In-Reply-To: <1285604596.3017.80.camel@edumazet-laptop>
On 27/09/2010 17:23, Eric Dumazet wrote:
> Le lundi 27 septembre 2010 à 15:22 +0000, jpo234 a écrit :
>> Hello all,
>> some time ago James Chapman sent patches that add L2TPv3 support to iproute2:
>> http://kerneltrap.org/mailarchive/linux-netdev/2010/3/18/6272266/thread
>> While the kernel support arrived in 2.6.35 the user space configuration support
>> still seems to be missing:
>> iproute2-2.6.35$ find . -type f -iname "*.c" | xargs fgrep -i l2tp
>> doesn't find anything.
>>
>> Can somebody clarify the current situation?
Stephen Hemminger (maintainer of iproute2) rejected the patches because
they would add a dependency of libnl to iproute2. iproute2 uses
libnetlink, not libnl. Stephen's objections are reasonable.
The l2tpv3 API uses generic-netlink (genl) which is handled by libnl
APIs very well (and is the main reason why libnl was chosen in the first
place). To recode using libnetlink would require working with low level
libnetlink helpers to build/parse genl messages at low level,
effectively reimplementing some of what is already handled by libnl. I
don't have motivation or time to do this, though I'm happy to support
someone else doing so.
As a quick solution, I posted a new utility, l2tpv3tun, which does the
same as the iproute2 l2tpv3 patches in a standalone utility. l2tpv3tun
is at ftp://ftp.openl2tp.org/releases/l2tpv3tun-0.1.tar.gz
> Hmm, this reminds me l2tp locking is buggy and not yet fixed.
>
> http://kerneltrap.org/mailarchive/linux-netdev/2010/4/20/6275106
>
> James, any chance you could fix the locking ?
This dropped off my radar. I'm too busy right now but I'll look at it as
soon as I can, unless someone else beats me to it.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: [PATCH v3] xmit_compl_seq: information to reclaim vmsplice buffers
From: Michael S. Tsirkin @ 2010-09-27 17:23 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, davem, sridharr
In-Reply-To: <alpine.DEB.1.00.1009231426450.11579@pokey.mtv.corp.google.com>
On Thu, Sep 23, 2010 at 02:35:16PM -0700, Tom Herbert wrote:
> In this patch we propose to adds some socket API to retrieve the
> "transmit completion sequence number", essentially a byte counter
> for the number of bytes that have been transmitted and will not be
> retransmitted. In the case of TCP, this should correspond to snd_una.
>
> The purpose of this API is to provide information to userspace about
> which buffers can be reclaimed when sending with vmsplice() on a
> socket.
>
> There are two methods for retrieving the completed sequence number:
> through a simple getsockopt (implemented here for TCP), as well as
> returning the value in the ancilary data of a recvmsg.
>
> The expected flow would be something like:
> - Connect is created
> - Initial completion seq # is retrieved through the sockopt, and is
> stored in userspace "compl_seq" variable for the connection.
> - Whenever a send is done, compl_seq += # bytes sent.
> - When doing a vmsplice the completion sequence number is saved
> for each user space buffer, buffer_compl_seq = compl_seq.
> - When recvmsg returns with a completion sequence number in
> ancillary data, any buffers cover by that sequence number
> (where buffer_compl_seq < recvmsg_compl_seq) are reclaimed
> and can be written to again.
> - If no data is receieved on a connection (recvmsg does not
> return), a timeout can be used to call the getsockopt and
> reclaim buffers as a fallback.
>
> Using recvmsg data in this manner is sort of a cheap way to get a
> "callback" for when a vmspliced buffer is consumed. It will work
> well for a client where the response causes recvmsg to return.
> On the server side it works well if there are a sufficient
> number of requests coming on the connection (resorting to the
> timeout if necessary as described above).
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Signed-off-by: Sridhar Raman <sridharr@google.com>
Can not packets referencing this memory
still be outstanding at the NIC device, if retransmit happens
before the ack but after the packet was passed to a device?
It's true that the reftransmit will likely get discarded
by the remote end, but this might be a security issue
if an application puts sensitive data in the buffer
and that gets inadvertently sent on the wire, can it not?
--
MST
^ 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