* Re: [PATCH 19/25] isdn/hardware/mISDN: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, isdn, u.kleine-koenig, tj, jkosina, netdev,
linux-kernel
In-Reply-To: <201007152102.38008.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 21:02:36 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 09/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, hsweeten, tj, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <201007152048.27535.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:48:26 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 08/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, hsweeten, tj, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <201007152045.33543.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:45:32 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 10/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, tj, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <201007152049.33395.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:49:32 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 07/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, roel.kluin, eric.dumazet, tj,
linux-atm-general, netdev, linux-kernel
In-Reply-To: <201007152044.12653.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:44:11 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 06/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, tj, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <201007152042.13091.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:42:12 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 03/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, ben, tj, linux-atm-general, netdev,
linux-kernel
In-Reply-To: <201007152038.21535.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:38:20 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 05/25] atm: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)
From: David Miller @ 2010-07-16 2:06 UTC (permalink / raw)
To: PeterHuewe
Cc: kernel-janitors, chas, eric.dumazet, tj, linux-atm-general,
netdev, linux-kernel
In-Reply-To: <201007152041.08976.PeterHuewe@gmx.de>
From: Peter Huewe <PeterHuewe@gmx.de>
Date: Thu, 15 Jul 2010 20:41:08 +0200
> From: Peter Huewe <peterhuewe@gmx.de>
>
> This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
> .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
> PCI_VDEVICE macro, and thus improves readability.
>
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [1/5] Spare skb to avoid starvation
From: David Miller @ 2010-07-16 1:39 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, pv-drivers, linux-kernel
In-Reply-To: <alpine.LRH.2.00.1007151656140.10176@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 15 Jul 2010 18:19:39 -0700 (PDT)
>
> Reposting this patch with struct vmxnet3_cmd_ring *ring made const
> according to Stephen's feedback.
Please address my feedback, which is that this is not the way to
handle this problem.
You can prevent all forms of starvation, without hacky spare-skbs or
things like that, by trying to allocate the replacement SKB _before_
sending the packet up to the stack.
If the replacement SKB allocation fails, you do not give the packet to
the network stack. Instead, you give it back to the card's RX ring.
See drivers/net/tg3.c, drivers/net/niu.c, etc. for examples of this.
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [4/5] Do not reset when the device is not opened
From: David Miller @ 2010-07-16 1:32 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, linux-kernel, pv-drivers, ronghua, matthieu
In-Reply-To: <alpine.LRH.2.00.1007151448260.25472@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Thu, 15 Jul 2010 18:20:52 -0700 (PDT)
> Is this what you suggest :
>
> ---
>
> Hold rtnl_lock to get the right link state.
It ought to work, but make sure that it is legal to take the
RTNL semaphore in all contexts in which this code block
might be called.
^ permalink raw reply
* Re: [PATCH] Drivers: net: 8139cp: Fixed 28 style errors, and 119 warnings.
From: David Miller @ 2010-07-16 1:30 UTC (permalink / raw)
To: joseph.kogut; +Cc: netdev, linux-kernel
In-Reply-To: <AANLkTikspw9LxFFsXJgWn30k2qCVu5zkOAq2FhWTpQvW@mail.gmail.com>
Besides the feedback given by Jeff Garzik, I would like to ask that
you please post your patches in a format other than as a binary
attachment. Plain text attachments are fine, for example.
That way your patch will be properly logged and tracked in
patchwork, and be easier for people to reply to and comment
upon.
Thank you.
^ permalink raw reply
* [PATCH 2.6.35-rc1] net-next: fix LRO feature update in vmxnet3
From: Shreyas Bhatewara @ 2010-07-16 1:28 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com
In-Reply-To: <alpine.LRH.2.00.1007151458580.10176@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Fix LRO feature update.
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_ethtool.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethtool.c b/drivers/net/vmxnet3/vmxnet3_ethtool.c
index de1ba14..7e4b5a8 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethtool.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethtool.c
@@ -291,10 +291,11 @@ vmxnet3_set_flags(struct net_device *netdev, u32 data)
/* update harware LRO capability accordingly */
if (lro_requested)
- adapter->shared->devRead.misc.uptFeatures &= UPT1_F_LRO;
+ adapter->shared->devRead.misc.uptFeatures |=
+ cpu_to_le64(UPT1_F_LRO);
else
adapter->shared->devRead.misc.uptFeatures &=
- ~UPT1_F_LRO;
+ cpu_to_le64(~UPT1_F_LRO);
VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
VMXNET3_CMD_UPDATE_FEATURE);
}
^ permalink raw reply related
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [5/5] Respect the interrupt type in VM configuration
From: Shreyas Bhatewara @ 2010-07-16 1:21 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com
In-Reply-To: <20100714.141118.260092331.davem@davemloft.net>
On Wed, 14 Jul 2010, David Miller wrote:
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> Date: Tue, 13 Jul 2010 17:51:39 -0700 (PDT)
>
> >
> > Do not ignore interrupt type in VM configuration
> >
> > When interrupt type is not auto, do not ignore the interrupt type set from
> > VM configuration.
> > Driver may not always respect the interrupt type in configuration but it
> > will certainly try to. Eg: if MSIx is configured and enabling MSIx fails
> > in driver, it fall back on MSI and then on INTx.
> >
> > Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
> ...
> > @@ -291,7 +291,7 @@ vmxnet3_set_flags(struct net_device *netdev, u32 data)
> >
> > /* update harware LRO capability accordingly */
> > if (lro_requested)
> > - adapter->shared->devRead.misc.uptFeatures &= UPT1_F_LRO;
> > + adapter->shared->devRead.misc.uptFeatures |= UPT1_F_LRO;
> > else
>
> This change has nothing to do with respecting the VM interrupt setting.
>
> Do not stuff unrelated changes into a commit.
> ...
Sorry about that. This is a fix I wanted to add and I did not operate stg
correctly. Reposting the patch w/o the feature update bits.
---
Respect the interrupt type set in VM configuration.
When interrupt type is not auto, do not ignore the interrupt type set from
VM configuration.
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 13 ++++++++++---
drivers/net/vmxnet3/vmxnet3_int.h | 4 ++--
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index c4d7e42..9282635 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2357,9 +2357,13 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
adapter->intr.mask_mode = (cfg >> 2) & 0x3;
if (adapter->intr.type == VMXNET3_IT_AUTO) {
- int err;
+ adapter->intr.type = VMXNET3_IT_MSIX;
+ }
#ifdef CONFIG_PCI_MSI
+ if (adapter->intr.type == VMXNET3_IT_MSIX) {
+ int err;
+
adapter->intr.msix_entries[0].entry = 0;
err = pci_enable_msix(adapter->pdev, adapter->intr.msix_entries,
VMXNET3_LINUX_MAX_MSIX_VECT);
@@ -2368,15 +2372,18 @@ vmxnet3_alloc_intr_resources(struct vmxnet3_adapter *adapter)
adapter->intr.type = VMXNET3_IT_MSIX;
return;
}
-#endif
+ adapter->intr.type = VMXNET3_IT_MSI;
+ }
+ if (adapter->intr.type == VMXNET3_IT_MSI) {
+ int err;
err = pci_enable_msi(adapter->pdev);
if (!err) {
adapter->intr.num_intrs = 1;
- adapter->intr.type = VMXNET3_IT_MSI;
return;
}
}
+#endif /* CONFIG_PCI_MSI */
adapter->intr.type = VMXNET3_IT_INTX;
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 9c2fe9a..d17fae6 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -68,10 +68,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.0.5.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.0.13.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01000500
+#define VMXNET3_DRIVER_VERSION_NUM 0x01000B00
/*
^ permalink raw reply related
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [4/5] Do not reset when the device is not opened
From: Shreyas Bhatewara @ 2010-07-16 1:20 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com, Ronghua Zhang, Matthieu Bucchianeri
In-Reply-To: <20100714.140718.115934967.davem@davemloft.net>
On Wed, 14 Jul 2010, David Miller wrote:
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> Date: Tue, 13 Jul 2010 17:49:52 -0700 (PDT)
>
> >
> > Do not reset when the device is not opened
> >
> > If a reset is scheduled, and the device goes thru close and open, it
> > may happen that reset and open may run in parallel.
> > The reset code now bails out if the device is not opened.
> >
> > Signed-off-by: Ronghua Zang <ronghua@vmware.com>
> > Signed-off-by: Matthieu Bucchianeri <matthieu@vmware.com>
> > Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> Testing IFF_UP is just making your race hole a little smaller but
> it isn't fixing the problem.
>
> In fact, there really isn't any legitimate reason for a driver
> to test the IFF_UP state bit. netif_running() is the correct
> test, and asynchronous work queue things like resets should
> synchronize with open/close using the RTNL lock so that your
> test of netif_running() is a stable one.
>
Is this what you suggest :
---
Hold rtnl_lock to get the right link state.
While asynchronously resetting the device, hold rtnl_lock to get the
right value from netif_running. If a reset is scheduled, and the device
goes thru close and open, it may happen that reset and open may run in
parallel. Holding rtnl_lock will avoid this.
---
drivers/net/vmxnet3/vmxnet3_drv.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 1b0ce8c..c4d7e42 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2420,6 +2420,7 @@ vmxnet3_reset_work(struct work_struct *data)
return;
/* if the device is closed, we must leave it alone */
+ rtnl_lock();
if (netif_running(adapter->netdev)) {
printk(KERN_INFO "%s: resetting\n", adapter->netdev->name);
vmxnet3_quiesce_dev(adapter);
@@ -2428,6 +2429,7 @@ vmxnet3_reset_work(struct work_struct *data)
} else {
printk(KERN_INFO "%s: already closed\n", adapter->netdev->name);
}
+ rtnl_unlock();
clear_bit(VMXNET3_STATE_BIT_RESETTING, &adapter->state);
}
^ permalink raw reply related
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [3/5] Initialize link state at probe time
From: Shreyas Bhatewara @ 2010-07-16 1:20 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com
In-Reply-To: <20100714.141054.48510602.davem@davemloft.net>
On Wed, 14 Jul 2010, David Miller wrote:
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> Date: Tue, 13 Jul 2010 17:48:55 -0700 (PDT)
>
> >
> > Initialize vmxnet3 link state at probe time
> >
> > This change initializes the state of link at the time when driver is
> > loaded. The ethtool output for 'link detected' and 'link speed'
> > is thus valid even before the interface is brought up.
> >
> > Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> You should never, ever, call netif_start_queue() on a device which has
> not been brought up.
>
> But that is what this patch is doing.
>
I do not understand why you say so. vmxnet3_check_link() is called in
probe() with affectTxQueue as false. Hence netif_start_queue() will not be
called before device is brought up.
vmxnet3_check_link() is again called with affectTxQueue as true in
vmxnet3_activate_dev() after device was activated.
^ permalink raw reply
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [2/5] Interrupt control bitmap
From: Shreyas Bhatewara @ 2010-07-16 1:20 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
pv-drivers@vmware.com, Ronghua Zhang
In-Reply-To: <20100714.140433.59678649.davem@davemloft.net>
On Wed, 14 Jul 2010, David Miller wrote:
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
> Date: Tue, 13 Jul 2010 17:48:04 -0700 (PDT)
>
> > - __le32 reserved[3];
> > + __le32 intrCtrl;
> > + __le32 reserved[2];
> > };
> >
> ...
> > + adapter->shared->devRead.intrConf.intrCtrl &= ~VMXNET3_IC_DISABLE_ALL;
> ...
> > + adapter->shared->devRead.intrConf.intrCtrl |= VMXNET3_IC_DISABLE_ALL;
> ...
> > + devRead->intrConf.intrCtrl |= VMXNET3_IC_DISABLE_ALL;
>
> You need to use cpu_to_le32() and similar when accessing this value.
>
> If you run "sparse" with endianness checking enabled you'll see
> warnings showing alerting you to this issue...
>
Reposting the patch with the endianness fix.
---
A new bit map 'intrCtrl' is introduced in the DriverShared area. The
driver Ashould update VMXNET3_IC_DISABLE_ALL bit before writing IMR.
Signed-off-by: Ronghua Zang <ronghua@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_defs.h | 6 +++++-
drivers/net/vmxnet3/vmxnet3_drv.c | 5 +++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_defs.h b/drivers/net/vmxnet3/vmxnet3_defs.h
index b4889e6..ca7727b 100644
--- a/drivers/net/vmxnet3/vmxnet3_defs.h
+++ b/drivers/net/vmxnet3/vmxnet3_defs.h
@@ -464,6 +464,9 @@ enum vmxnet3_intr_type {
/* addition 1 for events */
#define VMXNET3_MAX_INTRS 25
+/* value of intrCtrl */
+#define VMXNET3_IC_DISABLE_ALL 0x1 /* bit 0 */
+
struct Vmxnet3_IntrConf {
bool autoMask;
@@ -471,7 +474,8 @@ struct Vmxnet3_IntrConf {
u8 eventIntrIdx;
u8 modLevels[VMXNET3_MAX_INTRS]; /* moderation level for
* each intr */
- __le32 reserved[3];
+ __le32 intrCtrl;
+ __le32 reserved[2];
};
/* one bit per VLAN ID, the size is in the units of u32 */
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 5a50d10..df3d2ac 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -72,6 +72,8 @@ vmxnet3_enable_all_intrs(struct vmxnet3_adapter *adapter)
for (i = 0; i < adapter->intr.num_intrs; i++)
vmxnet3_enable_intr(adapter, i);
+ adapter->shared->devRead.intrConf.intrCtrl &=
+ cpu_to_le32(~VMXNET3_IC_DISABLE_ALL);
}
@@ -80,6 +82,8 @@ vmxnet3_disable_all_intrs(struct vmxnet3_adapter *adapter)
{
int i;
+ adapter->shared->devRead.intrConf.intrCtrl |=
+ cpu_to_le32(VMXNET3_IC_DISABLE_ALL);
for (i = 0; i < adapter->intr.num_intrs; i++)
vmxnet3_disable_intr(adapter, i);
}
@@ -1880,6 +1884,7 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter *adapter)
devRead->intrConf.modLevels[i] = adapter->intr.mod_levels[i];
devRead->intrConf.eventIntrIdx = adapter->intr.event_intr_idx;
+ devRead->intrConf.intrCtrl |= cpu_to_le32(VMXNET3_IC_DISABLE_ALL);
/* rx filter settings */
devRead->rxFilterConf.rxMode = 0;
^ permalink raw reply related
* Re: [PATCH 2.6.35-rc1] net-next: vmxnet3 fixes [1/5] Spare skb to avoid starvation
From: Shreyas Bhatewara @ 2010-07-16 1:19 UTC (permalink / raw)
To: netdev; +Cc: pv-drivers, linux-kernel, sbhatewara
In-Reply-To: <alpine.LRH.2.00.1007131743520.32055@localhost.localdomain>
Reposting this patch with struct vmxnet3_cmd_ring *ring made const
according to Stephen's feedback.
---
skb_alloc() failure can cause the ring to loose all packet reception. Avoid
this by introducing a spare buffer. The spare skb is only used when the ring
is "empty" and an skb allocation failure would cause the ring to starve. It is
never handed up to netif_rx(), and instead, when the rx_interrupt occurs, the
skb is shuffled back to reuse. Further use the incoming receive packet
interrupts as events to poll for skb allocation.
Signed-off-by: Michael Stolarchuk <stolarchuk@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_drv.c | 61 +++++++++++++++++++++++++++++++++++--
drivers/net/vmxnet3/vmxnet3_int.h | 12 ++++++-
2 files changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 989b742..5a50d10 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -541,7 +541,12 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
NET_IP_ALIGN);
if (unlikely(rbi->skb == NULL)) {
rq->stats.rx_buf_alloc_failure++;
- break;
+ /* starvation prevention */
+ if (vmxnet3_cmd_ring_desc_empty(
+ rq->rx_ring + ring_idx))
+ rbi->skb = rq->spare_skb;
+ else
+ break;
}
rbi->skb->dev = adapter->netdev;
@@ -611,6 +616,29 @@ vmxnet3_append_frag(struct sk_buff *skb, struct Vmxnet3_RxCompDesc *rcd,
}
+/*
+ * Free any pages which were attached to the frags of the spare skb. This can
+ * happen when the spare skb is attached to the rx ring to prevent starvation,
+ * but there was no issue with page allocation.
+ */
+
+static void
+vmxnet3_rx_spare_skb_free_frags(struct vmxnet3_adapter *adapter)
+{
+ struct sk_buff *skb = adapter->rx_queue.spare_skb;
+ int i;
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i];
+ BUG_ON(frag->page != 0);
+ put_page(frag->page);
+ frag->page = 0;
+ frag->size = 0;
+ }
+ skb_shinfo(skb)->nr_frags = 0;
+ skb->data_len = 0;
+}
+
+
static void
vmxnet3_map_pkt(struct sk_buff *skb, struct vmxnet3_tx_ctx *ctx,
struct vmxnet3_tx_queue *tq, struct pci_dev *pdev,
@@ -1060,8 +1088,12 @@ vmxnet3_rx_error(struct vmxnet3_rx_queue *rq, struct Vmxnet3_RxCompDesc *rcd,
* ctx->skb may be NULL if this is the first and the only one
* desc for the pkt
*/
- if (ctx->skb)
- dev_kfree_skb_irq(ctx->skb);
+ if (ctx->skb) {
+ if (ctx->skb == rq->spare_skb)
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ else
+ dev_kfree_skb_irq(ctx->skb);
+ }
ctx->skb = NULL;
}
@@ -1159,6 +1191,12 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
skb = ctx->skb;
if (rcd->eop) {
+ if (skb == rq->spare_skb) {
+ rq->stats.drop_total++;
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ ctx->skb = NULL;
+ goto rcd_done;
+ }
skb->len += skb->data_len;
skb->truesize += skb->data_len;
@@ -1244,6 +1282,14 @@ vmxnet3_rq_cleanup(struct vmxnet3_rx_queue *rq,
rq->uncommitted[ring_idx] = 0;
}
+ /* free starvation prevention skb if allocated */
+ if (rq->spare_skb) {
+ vmxnet3_rx_spare_skb_free_frags(adapter);
+ dev_kfree_skb(rq->spare_skb);
+ rq->spare_skb = NULL;
+ }
+
+
rq->comp_ring.gen = VMXNET3_INIT_GEN;
rq->comp_ring.next2proc = 0;
}
@@ -1325,6 +1371,15 @@ vmxnet3_rq_init(struct vmxnet3_rx_queue *rq,
}
vmxnet3_rq_alloc_rx_buf(rq, 1, rq->rx_ring[1].size - 1, adapter);
+ /* allocate ring starvation protection */
+ rq->spare_skb = dev_alloc_skb(PAGE_SIZE);
+ if (rq->spare_skb == NULL) {
+ vmxnet3_rq_cleanup(rq, adapter);
+ return -ENOMEM;
+ }
+
+
+
/* reset the comp ring */
rq->comp_ring.next2proc = 0;
memset(rq->comp_ring.base, 0, rq->comp_ring.size *
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 34f392f..9c2fe9a 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -149,6 +149,13 @@ vmxnet3_cmd_ring_desc_avail(struct vmxnet3_cmd_ring *ring)
ring->next2comp - ring->next2fill - 1;
}
+static inline bool
+vmxnet3_cmd_ring_desc_empty(const struct vmxnet3_cmd_ring *ring)
+{
+ return (ring->next2comp == ring->next2fill);
+}
+
+
struct vmxnet3_comp_ring {
union Vmxnet3_GenericDesc *base;
u32 size;
@@ -266,9 +273,10 @@ struct vmxnet3_rx_queue {
u32 qid2; /* rqID in RCD for buffer from 2nd ring */
u32 uncommitted[2]; /* # of buffers allocated since last RXPROD
* update */
- struct vmxnet3_rx_buf_info *buf_info[2];
- struct Vmxnet3_RxQueueCtrl *shared;
+ struct vmxnet3_rx_buf_info *buf_info[2];
+ struct Vmxnet3_RxQueueCtrl *shared;
struct vmxnet3_rq_driver_stats stats;
+ struct sk_buff *spare_skb; /* starvation skb */
} __attribute__((__aligned__(SMP_CACHE_BYTES)));
#define VMXNET3_LINUX_MAX_MSIX_VECT 1
^ permalink raw reply related
* Re: [PATCH] Drivers: net: 8139cp: Fixed 28 style errors, and 119 warnings.
From: Jeff Garzik @ 2010-07-16 0:57 UTC (permalink / raw)
To: Joseph Kogut; +Cc: davem, netdev, linux-kernel
In-Reply-To: <AANLkTikspw9LxFFsXJgWn30k2qCVu5zkOAq2FhWTpQvW@mail.gmail.com>
> -/* The following settings are log_2(bytes)-4: 0 == 16 bytes .. 6==1024, 7==end of packet. */
> -#define RX_FIFO_THRESH 5 /* Rx buffer level before first PCI xfer. */
> +/* The following settings are log_2(bytes)-4: 0 == 16 bytes .. 6 == 1024, 7 == end of packet. */
> +#define RX_FIFO_THRESH 5 /* Rx buffer level before first PCI xfer. */
useless noise
> - unsigned wol_enabled : 1; /* Is Wake-on-LAN enabled? */
> + unsigned wol_enabled:1; /* Is Wake-on-LAN enabled? */
not an improvement
> - if (wol->wolopts & WAKE_PHY) options |= LinkUp;
> - if (wol->wolopts & WAKE_MAGIC) options |= MagicPacket;
> + if (wol->wolopts & WAKE_PHY)
> + options |= LinkUp;
> + if (wol->wolopts & WAKE_MAGIC)
> + options |= MagicPacket;
ditto
> - if (wol->wolopts & WAKE_UCAST) options |= UWF;
> - if (wol->wolopts & WAKE_BCAST) options |= BWF;
> - if (wol->wolopts & WAKE_MCAST) options |= MWF;
> + if (wol->wolopts & WAKE_UCAST)
> + options |= UWF;
> + if (wol->wolopts & WAKE_BCAST)
> + options |= BWF;
> + if (wol->wolopts & WAKE_MCAST)
> + options |= MWF;
ditto
>
> - if (options & UWF) wol->wolopts |= WAKE_UCAST;
> - if (options & BWF) wol->wolopts |= WAKE_BCAST;
> - if (options & MWF) wol->wolopts |= WAKE_MCAST;
> + options = cpr8(Config5);
> + if (options & UWF)
> + wol->wolopts |= WAKE_UCAST;
> + if (options & BWF)
> + wol->wolopts |= WAKE_BCAST;
> + if (options & MWF)
> + wol->wolopts |= WAKE_MCAST;
ditto
^ permalink raw reply
* Re: [PATCH 05/11] tulip: formatting of pointers in printk()
From: Kyle McMartin @ 2010-07-16 0:46 UTC (permalink / raw)
To: David Miller
Cc: segooon, kernel-janitors, grundler, kyle, joe, jpirko, ben,
grant.likely, netdev, linux-kernel, devicetree-discuss
In-Reply-To: <20100714.150739.193711125.davem@davemloft.net>
On Wed, Jul 14, 2010 at 03:07:39PM -0700, David Miller wrote:
> Since patch #5 and #6 are doing the same change to different
> files in the same driver, I combined them into one commit.
>
Thanks, Dave!
--Kyle
^ permalink raw reply
* Re: Raise initial congestion window size / speedup slow start?
From: H.K. Jerry Chu @ 2010-07-16 0:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Rick Jones, Bill Fink, Hagen Paul Pfeifer, David Miller, lists,
davidsen, linux-kernel, netdev
In-Reply-To: <20100715134857.38d519c5@nehalam>
I don't even consider a modest IW increase to 10 is aggressive. The scaling
of IW is only adequate IMO given the huge b/w growth in the past
decade. Remember there could be plenty of flows sending large cwnd
bursts at
twice the bottleneck link rate at any point of time in the network anyway so
the "fairness" question may already be ill-defined. In any case we're
trying to conduct some experiment in a private testbed to hopefully
get some insights
with real data.
Jerry
On Thu, Jul 15, 2010 at 1:48 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Thu, 15 Jul 2010 12:51:22 -0700
> Rick Jones <rick.jones2@hp.com> wrote:
>
>> I have to wonder if the only heuristic one could employ for divining the initial
>> congestion window is to be either pessimistic/conservative or
>> optimistic/liberal. Or for that matter the only one one really needs here?
>>
>> That's what it comes down to doesn't it? At any one point in time, we don't
>> *really* know the state of the network and whether it can handle the load we
>> might wish to put upon it. We are always reacting to it. Up until now, it has
>> been felt necessary to be pessimistic/conservative at time of connection
>> establishment and not rely as much on the robustness of the "control" part of
>> avoidance and control.
>>
>> Now, the folks at Google have lots of data to suggest we don't need to be so
>> pessimistic/conservative and so we have to decide if we are willing to be more
>> optimistic/liberal. Broadly handwaving, the "netdev we" seems to be willing to
>> be more optimistic/liberal in at least a few cases, and the question comes down
>> to whether or not the "IETF we" will be similarly willing.
>
> I am not convinced that a host being aggressive with initial cwnd (Linux) would
> not end up unfairly monopolizing available bandwidth compared to older more conservative
> implementations (Windows). Whether fairness is important or not is another debate.
>
>
^ permalink raw reply
* Re: [ipmr] ipmr: Don't leak memory if fib lookup fails.
From: Ben Greear @ 2010-07-16 0:04 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <1279236153-23699-1-git-send-email-greearb@candelatech.com>
On 07/15/2010 04:22 PM, Ben Greear wrote:
> This was detected using two mcast router tables. The
> pimreg for the second interface did not have a specific
> mrule, so packets received by it were handled by the
> default table, which had nothing configured.
I just realized this should be applied against 2.6.35-pre, not 2.6.34.
Thanks,
Ben
> This caused the ipmr_fib_lookup to fail, causing
> the memory leak.
>
> Signed-off-by: Ben Greear<greearb@candelatech.com>
> ---
> :100644 100644 ed2f911... f112ad8... M net/ipv4/ipmr.c
> net/ipv4/ipmr.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index ed2f911..f112ad8 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -442,8 +442,10 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
> int err;
>
> err = ipmr_fib_lookup(net,&fl,&mrt);
> - if (err< 0)
> + if (err< 0) {
> + kfree_skb(skb);
> return err;
> + }
>
> read_lock(&mrt_lock);
> dev->stats.tx_bytes += skb->len;
> @@ -1729,8 +1731,10 @@ int ip_mr_input(struct sk_buff *skb)
> goto dont_forward;
>
> err = ipmr_fib_lookup(net,&skb_rtable(skb)->fl,&mrt);
> - if (err< 0)
> + if (err< 0) {
> + kfree_skb(skb);
> return err;
> + }
>
> if (!local) {
> if (IPCB(skb)->opt.router_alert) {
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* igb: 2.6.34.1: kernel warning at igb_main.c:2080
From: Ben Greear @ 2010-07-15 23:56 UTC (permalink / raw)
To: NetDev
We just saw this kernel warning on 2.6.34.1 + a few patches from the pending stable queue,
plus our own hacks (though none to igb).
We were running a modified version of pktgen traffic and at the same time
bounced the port.
This warning didn't seem to cause any real problems.
Please let us know if you would like any additional information.
]# lspci|grep Ethern
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
05:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
05:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
06:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
06:00.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network Connection (rev 02)
Jul 15 16:36:01 localhost kernel: ------------[ cut here ]------------
Jul 15 16:36:01 localhost kernel: WARNING: at /home/greearb/git/linux-2.6.dev.34.y/drivers/net/igb/igb_main.c:2080 igb_close+0x28/0x9f [igb]()
Jul 15 16:36:01 localhost kernel: Hardware name: X8STi
Jul 15 16:36:01 localhost kernel: Modules linked in: bridge arc4 michael_mic wanlink(P) 8021q garp xt_CT iptable_raw ipt_addrtype xt_DSCP xt_dscp xt_string
xt_owner xt_NFQUEUE xt_multiport xt_mark xt_iprange xt_hashlimit xt_CONNMARK xt_connmark stp llc veth fuse macvlan bpctl_mod pktgen iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 dm_multipath uinput i2c_i801 iTCO_wdt i2c_core ioatdma e1000e igb pcspkr
iTCO_vendor_support dca ata_generic pata_acpi [last unloaded: nf_nat]
Jul 15 16:36:01 localhost kernel: Pid: 17516, comm: ip Tainted: P 2.6.34.1 #2
Jul 15 16:36:01 localhost kernel: Call Trace:
Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>] ? igb_close+0x28/0x9f [igb]
Jul 15 16:36:01 localhost kernel: [<ffffffff81041bb6>] warn_slowpath_common+0x77/0x8f
Jul 15 16:36:01 localhost kernel: [<ffffffff81041bdd>] warn_slowpath_null+0xf/0x11
Jul 15 16:36:01 localhost kernel: [<ffffffffa002a37f>] igb_close+0x28/0x9f [igb]
Jul 15 16:36:01 localhost kernel: [<ffffffff8133c626>] __dev_close+0x73/0x86
Jul 15 16:36:01 localhost kernel: [<ffffffff8133a719>] __dev_change_flags+0xa8/0x12b
Jul 15 16:36:01 localhost kernel: [<ffffffff8133c2aa>] dev_change_flags+0x1c/0x51
Jul 15 16:36:01 localhost kernel: [<ffffffff813466bc>] do_setlink+0x273/0x482
Jul 15 16:36:01 localhost kernel: [<ffffffff810ab1bb>] ? zone_statistics+0x5e/0x63
Jul 15 16:36:01 localhost kernel: [<ffffffff8134755e>] rtnl_newlink+0x26c/0x422
Jul 15 16:36:01 localhost kernel: [<ffffffff81345a06>] ? nla_nest_start+0x1d/0x31
Jul 15 16:36:01 localhost kernel: [<ffffffff810ca997>] ? virt_to_head_page+0x9/0x2a
Jul 15 16:36:01 localhost kernel: [<ffffffff813dd1f5>] ? __mutex_lock_common+0x38e/0x3ac
Jul 15 16:36:01 localhost kernel: [<ffffffff81346ffb>] rtnetlink_rcv_msg+0x1d9/0x1f7
Jul 15 16:36:01 localhost kernel: [<ffffffff81346e22>] ? rtnetlink_rcv_msg+0x0/0x1f7
Jul 15 16:36:01 localhost kernel: [<ffffffff81356939>] netlink_rcv_skb+0x3e/0x8e
Jul 15 16:36:01 localhost kernel: [<ffffffff81346cc9>] rtnetlink_rcv+0x20/0x29
Jul 15 16:36:01 localhost kernel: [<ffffffff813567b2>] netlink_unicast+0xea/0x151
Jul 15 16:36:01 localhost kernel: [<ffffffff8133545c>] ? memcpy_fromiovec+0x42/0x73
Jul 15 16:36:01 localhost kernel: [<ffffffff81357bc8>] netlink_sendmsg+0x242/0x255
Jul 15 16:36:01 localhost kernel: [<ffffffff8132a771>] ? __sock_recvmsg_nosec+0x29/0x2b
Jul 15 16:36:01 localhost kernel: [<ffffffff8132bd02>] __sock_sendmsg+0x56/0x5f
Jul 15 16:36:01 localhost kernel: [<ffffffff8132c127>] sock_sendmsg+0xa3/0xbc
Jul 15 16:36:01 localhost kernel: [<ffffffff813351e5>] ? copy_from_user+0x28/0x30
Jul 15 16:36:01 localhost kernel: [<ffffffff8133555e>] ? verify_iovec+0x52/0x95
Jul 15 16:36:01 localhost kernel: [<ffffffff8132c368>] sys_sendmsg+0x1c6/0x22a
Jul 15 16:36:01 localhost kernel: [<ffffffff810a277f>] ? lru_cache_add_lru+0x38/0x3d
Jul 15 16:36:01 localhost kernel: [<ffffffff813de23e>] ? _raw_spin_unlock+0x2d/0x38
Jul 15 16:36:01 localhost kernel: [<ffffffff810ad802>] ? spin_unlock+0x9/0xb
Jul 15 16:36:01 localhost kernel: [<ffffffff810b0138>] ? handle_mm_fault+0x6d3/0x6f3
Jul 15 16:36:01 localhost kernel: [<ffffffff810b3a0a>] ? __vma_link_rb+0x2b/0x2d
Jul 15 16:36:01 localhost kernel: [<ffffffff810b45f7>] ? vma_link+0xcd/0xcf
Jul 15 16:36:01 localhost kernel: [<ffffffff810d9369>] ? fget_light+0x39/0x87
Jul 15 16:36:01 localhost kernel: [<ffffffff81083b91>] ? audit_syscall_entry+0xfe/0x12a
Jul 15 16:36:01 localhost kernel: [<ffffffff81009ac2>] system_call_fastpath+0x16/0x1b
Jul 15 16:36:01 localhost kernel: ---[ end trace 75242fae6dbfdf6d ]---
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH RFC] act_cpu: packet distributing
From: Changli Gao @ 2010-07-15 23:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: hadi, David S. Miller, Patrick McHardy, Tom Herbert, netdev
In-Reply-To: <1279212897.2496.133.camel@edumazet-laptop>
On Fri, Jul 16, 2010 at 12:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 15 juillet 2010 à 08:48 -0400, jamal a écrit :
>>
>> RCU maybe a little trickier here Eric. Actions could be shared i.e.
>> example, it is possible to have a policer action restricting rates for a
>> group of flows across multiple netdevices etc. Since action stats get
>> written to by different CPUs concurrently. It could be probably done if
>> one was to implement per-cpu stats which get summed-up when user space
>> asks.
>
> It's certainly tricky, but is act_cpu useful in its current shape, based
> on an infrastructure that had to use a lock because of exact
> rates/accounting ?
>
> I dont understand how distributing packets to different cpus, if going
> through a central lock can be an improvement. Changli patches are most
> of the time not documented, and no performance data is provided.
>
The tcf_lock is per-instance, so I should not an issue here if the
corresponding NIC isn't an multiqueue NIC or the instance is
per-rx-queue. I agree
the performance data is necessary and I'll publish it in the formal
patch.
> Even if we solve this locking problem, using percpu variables, act_cpu
> hits another problem :
>
> The socket refcount, taken by the 'master' cpu, and released by the
> consumer cpu.
This is why I asked if I can assign sk to skb.
>
> RFS provides sort of a lazy flow-based distribution without central lock
> or cache line ping pongs. Why Changli dont use this, we dont know yet.
>
The fact is I don't know how to do this. I'll work on this issue later.
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [ipmr] ipmr: Don't leak memory if fib lookup fails.
From: Ben Greear @ 2010-07-15 23:22 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
This was detected using two mcast router tables. The
pimreg for the second interface did not have a specific
mrule, so packets received by it were handled by the
default table, which had nothing configured.
This caused the ipmr_fib_lookup to fail, causing
the memory leak.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 ed2f911... f112ad8... M net/ipv4/ipmr.c
net/ipv4/ipmr.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index ed2f911..f112ad8 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -442,8 +442,10 @@ static netdev_tx_t reg_vif_xmit(struct sk_buff *skb, struct net_device *dev)
int err;
err = ipmr_fib_lookup(net, &fl, &mrt);
- if (err < 0)
+ if (err < 0) {
+ kfree_skb(skb);
return err;
+ }
read_lock(&mrt_lock);
dev->stats.tx_bytes += skb->len;
@@ -1729,8 +1731,10 @@ int ip_mr_input(struct sk_buff *skb)
goto dont_forward;
err = ipmr_fib_lookup(net, &skb_rtable(skb)->fl, &mrt);
- if (err < 0)
+ if (err < 0) {
+ kfree_skb(skb);
return err;
+ }
if (!local) {
if (IPCB(skb)->opt.router_alert) {
--
1.6.2.5
^ permalink raw reply related
* Re: Raise initial congestion window size / speedup slow start?
From: Bill Davidsen @ 2010-07-15 23:14 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, linux-kernel
In-Reply-To: <20100714.111553.104052157.davem@davemloft.net>
David Miller wrote:
> From: Bill Davidsen <davidsen@tmr.com>
> Date: Wed, 14 Jul 2010 11:21:15 -0400
>
>> You may have to go into /proc/sys/net/core and crank up the
>> rmem_* settings, depending on your distribution.
>
> You should never, ever, have to touch the various networking sysctl
> values to get good performance in any normal setup. If you do, it's a
> bug, report it so we can fix it.
>
> I cringe every time someone says to do this, so please do me a favor
> and don't spread this further. :-)
>
I think transit time measured in 1/10th sec would disqualify this as a "normal
setup."
High bandwidth and high latency don't work well because you get "send until the
window is full then wait for ack" and poor performance. I saw this with sat feed
to Wyoming from GE's Research Center in upstate NY in the late 80's or early
90's. (I think this was NYserNet at that time). I did feeds from NYC area to
California and Hawaii with SBC in the early to mid 2k years. In every case
SunOS, Solaris, AIX and Linux all failed to hit anything like reasonable
transfer speeds without manually tweaking, and I got the advice on increasing
window size from network engineers at ISPs and backbone providers.
The O.P. may have other issues, and may benefit from doing other things as well,
but raising window size is a reasonable thing to do on links with RTT in
hundreds of ms, and it's easy to try without changing config files.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ 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