* Re: [GENETLINK]: Fix adjustment of number of multicast groups
From: David Miller @ 2007-07-24 22:34 UTC (permalink / raw)
To: tgraf; +Cc: johannes, netdev
In-Reply-To: <20070724094514.GD9285@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 24 Jul 2007 11:45:14 +0200
> The current calculation of the maximum number of genetlink
> multicast groups seems odd, fix it.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks.
^ permalink raw reply
* [FIX] NET: Fix sch_api and sch_prio to properly set and detect the root qdisc
From: PJ Waskiewicz @ 2007-07-24 22:33 UTC (permalink / raw)
To: davem; +Cc: netdev, kaber
This is a patch from Patrick McHardy to fix the sch_api code, which I
went ahead and tested and made a slight fix to. This also includes
the fix to sch_prio based on Patrick's patch.
The sch->parent handle should contain the parent qdisc ID. When the
qdisc is the root qdisc (TC_H_ROOT), the parent handle should be the
value TC_H_ROOT. This fixes sch_api to set this correctly on
qdisc_create() for both ingress and egress qdiscs.
Change this check in prio_tune() so that only the root qdisc can be
multiqueue-enabled; use sch->parent instead of sch->handle.
--
PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
^ permalink raw reply
* Re: [GENETLINK]: Correctly report errors while registering a multicast group
From: David Miller @ 2007-07-24 22:35 UTC (permalink / raw)
To: tgraf; +Cc: johannes, netdev
In-Reply-To: <20070724094427.GC9285@postel.suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Tue, 24 Jul 2007 11:44:27 +0200
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Also applied, thanks Thomas.
^ permalink raw reply
* [PATCH 0/2][RFC] Update network drivers to use devres
From: bphilips @ 2007-07-24 22:39 UTC (permalink / raw)
To: netdev
These patches update the network driver core and the e100 driver to use devres.
Devres is a simple resource manager for device drivers, see
Documentation/driver-model/devres.txt for more information.
If the RFC goes well I will create patches to update all applicable network
drivers.
Applies against 2.6.22
^ permalink raw reply
* [PATCH 1/2][RFC] Update net core to use devres.
From: bphilips @ 2007-07-24 22:39 UTC (permalink / raw)
To: netdev; +Cc: Brandon Philips
In-Reply-To: <11853167931415-git-send-email-bphilips@suse.de>
* netdev_pci_remove_one() can replace simple pci device remove
functions
* devm_alloc_netdev() is like alloc_netdev but allocates memory using devres.
alloc_netdev() can be removed once all drivers use devres.
Applies against 2.6.22
Signed-off-by: Brandon Philips <bphilips@suse.de>
---
include/linux/etherdevice.h | 2 +
include/linux/netdevice.h | 5 ++++
net/core/dev.c | 48 ++++++++++++++++++++++++++++++++++++++++----
net/ethernet/eth.c | 6 +++++
4 files changed, 57 insertions(+), 4 deletions(-)
Index: linux-2.6/include/linux/netdevice.h
===================================================================
--- linux-2.6.orig/include/linux/netdevice.h
+++ linux-2.6/include/linux/netdevice.h
@@ -622,6 +622,7 @@ extern int dev_queue_xmit(struct sk_buf
extern int register_netdevice(struct net_device *dev);
extern void unregister_netdevice(struct net_device *dev);
extern void free_netdev(struct net_device *dev);
+extern void netdev_pci_remove_one(struct pci_dev *pdev);
extern void synchronize_net(void);
extern int register_netdevice_notifier(struct notifier_block *nb);
extern int unregister_netdevice_notifier(struct notifier_block *nb);
@@ -992,6 +993,10 @@ static inline void netif_tx_disable(stru
extern void ether_setup(struct net_device *dev);
/* Support for loadable net-drivers */
+
+extern struct net_device *devm_alloc_netdev(struct device *dev,
+ int sizeof_priv, const char *name,
+ void (*setup)(struct net_device *));
extern struct net_device *alloc_netdev(int sizeof_priv, const char *name,
void (*setup)(struct net_device *));
extern int register_netdev(struct net_device *dev);
Index: linux-2.6/net/core/dev.c
===================================================================
--- linux-2.6.orig/net/core/dev.c
+++ linux-2.6/net/core/dev.c
@@ -89,6 +89,7 @@
#include <linux/interrupt.h>
#include <linux/if_ether.h>
#include <linux/netdevice.h>
+#include <linux/pci.h>
#include <linux/etherdevice.h>
#include <linux/notifier.h>
#include <linux/skbuff.h>
@@ -3343,7 +3344,8 @@ static struct net_device_stats *internal
}
/**
- * alloc_netdev - allocate network device
+ * __alloc_netdev - allocate network device
+ * @dev: managed device responsible for mem; NULL if not managed
* @sizeof_priv: size of private data to allocate space for
* @name: device name format string
* @setup: callback to initialize device
@@ -3351,8 +3353,8 @@ static struct net_device_stats *internal
* Allocates a struct net_device with private data area for driver use
* and performs basic initialization.
*/
-struct net_device *alloc_netdev(int sizeof_priv, const char *name,
- void (*setup)(struct net_device *))
+struct net_device *__alloc_netdev(struct device *gendev, int sizeof_priv,
+ const char *name, void (*setup)(struct net_device *))
{
void *p;
struct net_device *dev;
@@ -3364,7 +3366,11 @@ struct net_device *alloc_netdev(int size
alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST;
alloc_size += sizeof_priv + NETDEV_ALIGN_CONST;
- p = kzalloc(alloc_size, GFP_KERNEL);
+ if (dev == NULL)
+ p = kzalloc(alloc_size, GFP_KERNEL);
+ else
+ p = devm_kzalloc(gendev, alloc_size, GFP_KERNEL);
+
if (!p) {
printk(KERN_ERR "alloc_netdev: Unable to allocate device.\n");
return NULL;
@@ -3382,8 +3388,23 @@ struct net_device *alloc_netdev(int size
strcpy(dev->name, name);
return dev;
}
+
+struct net_device *devm_alloc_netdev(struct device *dev, int sizeof_priv, const
+ char *name, void (*setup)(struct net_device *))
+{
+ return __alloc_netdev(dev, sizeof_priv, name, setup);
+}
+EXPORT_SYMBOL(devm_alloc_netdev);
+
+struct net_device *alloc_netdev(int sizeof_priv, const char *name,
+ void (*setup)(struct net_device *))
+{
+ return __alloc_netdev(NULL, sizeof_priv, name, setup);
+}
EXPORT_SYMBOL(alloc_netdev);
+
+
/**
* free_netdev - free network device
* @dev: device
@@ -3411,6 +3432,25 @@ void free_netdev(struct net_device *dev)
#endif
}
+/**
+ * free_netdev - free network device
+ * @dev: device
+ *
+ * This function does the last stage of destroying an allocated device
+ * interface. The reference to the device object is released.
+ * If this is the last reference then it will be freed.
+ */
+void netdev_pci_remove_one(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ if (netdev) {
+ unregister_netdev(netdev);
+ pci_set_drvdata(pdev, NULL);
+ }
+}
+EXPORT_SYMBOL(netdev_pci_remove_one);
+
+
/* Synchronize with packet receive processing. */
void synchronize_net(void)
{
Index: linux-2.6/include/linux/etherdevice.h
===================================================================
--- linux-2.6.orig/include/linux/etherdevice.h
+++ linux-2.6/include/linux/etherdevice.h
@@ -40,6 +40,8 @@ extern int eth_header_cache(struct neig
struct hh_cache *hh);
extern struct net_device *alloc_etherdev(int sizeof_priv);
+extern struct net_device *devm_alloc_etherdev(struct device *dev,
+ int sizeof_priv);
static inline void eth_copy_and_sum (struct sk_buff *dest,
const unsigned char *src,
int len, int base)
Index: linux-2.6/net/ethernet/eth.c
===================================================================
--- linux-2.6.orig/net/ethernet/eth.c
+++ linux-2.6/net/ethernet/eth.c
@@ -333,3 +333,9 @@ struct net_device *alloc_etherdev(int si
return alloc_netdev(sizeof_priv, "eth%d", ether_setup);
}
EXPORT_SYMBOL(alloc_etherdev);
+
+struct net_device *devm_alloc_etherdev(struct device *dev, int sizeof_priv)
+{
+ return devm_alloc_netdev(dev, sizeof_priv, "eth%d", ether_setup);
+}
+EXPORT_SYMBOL(devm_alloc_etherdev);
^ permalink raw reply
* [PATCH 2/2][RFC] Update e100 driver to use devres.
From: bphilips @ 2007-07-24 22:42 UTC (permalink / raw)
To: netdev; +Cc: Brandon Philips
devres manages device resources and is currently used by all libata low level
drivers. It can greatly reduce the complexity of the error handling on probe
and the device removal functions.
For example the e100_free() function and all of the gotos in e100_probe have
been removed. Also, e100_remove() has been deleted and replaced with a much
simpler netdev_pci_remove_one() function that should be able to handle any PCI
net device that doesn't require any teardown besides resource deallocation.
Applies against 2.6.22.
Signed-off-by: Brandon Philips <bphilips@suse.de>
---
drivers/net/e100.c | 73 +++++++++++++----------------------------------------
1 file changed, 19 insertions(+), 54 deletions(-)
Index: linux-2.6/drivers/net/e100.c
===================================================================
--- linux-2.6.orig/drivers/net/e100.c
+++ linux-2.6/drivers/net/e100.c
@@ -2514,18 +2514,11 @@ static int e100_do_ioctl(struct net_devi
static int e100_alloc(struct nic *nic)
{
- nic->mem = pci_alloc_consistent(nic->pdev, sizeof(struct mem),
- &nic->dma_addr);
- return nic->mem ? 0 : -ENOMEM;
-}
+ struct device *dev = &nic->pdev->dev;
-static void e100_free(struct nic *nic)
-{
- if(nic->mem) {
- pci_free_consistent(nic->pdev, sizeof(struct mem),
- nic->mem, nic->dma_addr);
- nic->mem = NULL;
- }
+ nic->mem = dmam_alloc_coherent(dev, sizeof(struct mem),
+ &nic->dma_addr, GFP_ATOMIC);
+ return nic->mem ? 0 : -ENOMEM;
}
static int e100_open(struct net_device *netdev)
@@ -2552,7 +2545,7 @@ static int __devinit e100_probe(struct p
struct nic *nic;
int err;
- if(!(netdev = alloc_etherdev(sizeof(struct nic)))) {
+ if (!(netdev = devm_alloc_etherdev(&pdev->dev, sizeof(struct nic)))) {
if(((1 << debug) - 1) & NETIF_MSG_PROBE)
printk(KERN_ERR PFX "Etherdev alloc failed, abort.\n");
return -ENOMEM;
@@ -2582,26 +2575,26 @@ static int __devinit e100_probe(struct p
nic->msg_enable = (1 << debug) - 1;
pci_set_drvdata(pdev, netdev);
- if((err = pci_enable_device(pdev))) {
+ if ((err = pcim_enable_device(pdev))) {
DPRINTK(PROBE, ERR, "Cannot enable PCI device, aborting.\n");
- goto err_out_free_dev;
+ return err;
}
if(!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM)) {
DPRINTK(PROBE, ERR, "Cannot find proper PCI device "
"base address, aborting.\n");
err = -ENODEV;
- goto err_out_disable_pdev;
+ return err;
}
if((err = pci_request_regions(pdev, DRV_NAME))) {
DPRINTK(PROBE, ERR, "Cannot obtain PCI resources, aborting.\n");
- goto err_out_disable_pdev;
+ return err;
}
if((err = pci_set_dma_mask(pdev, DMA_32BIT_MASK))) {
DPRINTK(PROBE, ERR, "No usable DMA configuration, aborting.\n");
- goto err_out_free_res;
+ return err;
}
SET_MODULE_OWNER(netdev);
@@ -2610,11 +2603,11 @@ static int __devinit e100_probe(struct p
if (use_io)
DPRINTK(PROBE, INFO, "using i/o access mode\n");
- nic->csr = pci_iomap(pdev, (use_io ? 1 : 0), sizeof(struct csr));
+ nic->csr = pcim_iomap(pdev, (use_io ? 1 : 0), sizeof(struct csr));
if(!nic->csr) {
DPRINTK(PROBE, ERR, "Cannot map device registers, aborting.\n");
err = -ENOMEM;
- goto err_out_free_res;
+ return err;
}
if(ent->driver_data)
@@ -2647,11 +2640,11 @@ static int __devinit e100_probe(struct p
if((err = e100_alloc(nic))) {
DPRINTK(PROBE, ERR, "Cannot alloc driver memory, aborting.\n");
- goto err_out_iounmap;
+ return err;
}
if((err = e100_eeprom_load(nic)))
- goto err_out_free;
+ return err;
e100_phy_init(nic);
@@ -2661,8 +2654,8 @@ static int __devinit e100_probe(struct p
if (!eeprom_bad_csum_allow) {
DPRINTK(PROBE, ERR, "Invalid MAC address from "
"EEPROM, aborting.\n");
- err = -EAGAIN;
- goto err_out_free;
+
+ return -EAGAIN;
} else {
DPRINTK(PROBE, ERR, "Invalid MAC address from EEPROM, "
"you MUST configure one.\n");
@@ -2682,7 +2675,7 @@ static int __devinit e100_probe(struct p
strcpy(netdev->name, "eth%d");
if((err = register_netdev(netdev))) {
DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n");
- goto err_out_free;
+ return err;
}
DPRINTK(PROBE, INFO, "addr 0x%llx, irq %d, "
@@ -2692,36 +2685,8 @@ static int __devinit e100_probe(struct p
netdev->dev_addr[3], netdev->dev_addr[4], netdev->dev_addr[5]);
return 0;
-
-err_out_free:
- e100_free(nic);
-err_out_iounmap:
- pci_iounmap(pdev, nic->csr);
-err_out_free_res:
- pci_release_regions(pdev);
-err_out_disable_pdev:
- pci_disable_device(pdev);
-err_out_free_dev:
- pci_set_drvdata(pdev, NULL);
- free_netdev(netdev);
- return err;
}
-static void __devexit e100_remove(struct pci_dev *pdev)
-{
- struct net_device *netdev = pci_get_drvdata(pdev);
-
- if(netdev) {
- struct nic *nic = netdev_priv(netdev);
- unregister_netdev(netdev);
- e100_free(nic);
- iounmap(nic->csr);
- free_netdev(netdev);
- pci_release_regions(pdev);
- pci_disable_device(pdev);
- pci_set_drvdata(pdev, NULL);
- }
-}
#ifdef CONFIG_PM
static int e100_suspend(struct pci_dev *pdev, pm_message_t state)
@@ -2825,7 +2790,7 @@ static pci_ers_result_t e100_io_slot_res
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- if (pci_enable_device(pdev)) {
+ if (pcim_enable_device(pdev)) {
printk(KERN_ERR "e100: Cannot re-enable PCI device after reset.\n");
return PCI_ERS_RESULT_DISCONNECT;
}
@@ -2872,7 +2837,7 @@ static struct pci_driver e100_driver = {
.name = DRV_NAME,
.id_table = e100_id_table,
.probe = e100_probe,
- .remove = __devexit_p(e100_remove),
+ .remove = __devexit_p(netdev_pci_remove_one),
#ifdef CONFIG_PM
/* Power Management hooks */
.suspend = e100_suspend,
^ permalink raw reply
* Re: [PATCH 1/2][RFC] Update net core to use devres.
From: Al Viro @ 2007-07-24 22:51 UTC (permalink / raw)
To: bphilips; +Cc: netdev
In-Reply-To: <11853167964115-git-send-email-bphilips@suse.de>
On Tue, Jul 24, 2007 at 03:39:52PM -0700, bphilips@suse.de wrote:
> * netdev_pci_remove_one() can replace simple pci device remove
> functions
>
> * devm_alloc_netdev() is like alloc_netdev but allocates memory using devres.
> alloc_netdev() can be removed once all drivers use devres.
Ewwww... What the hell for? To make sure that we have struct device
for everything, whether we need it or not? Have you actually read
through drivers/net? I mean, _really_ read through it, looking for
ugly cases...
I've done just that several times and I'm sorry, but I would classify
that project as hopeless. It's way, _way_ more diverse than SATA...
^ permalink raw reply
* Re: [PATCH 1/2][RFC] Update net core to use devres.
From: Al Viro @ 2007-07-24 23:09 UTC (permalink / raw)
To: bphilips; +Cc: netdev
In-Reply-To: <20070724225134.GV21668@ftp.linux.org.uk>
On Tue, Jul 24, 2007 at 11:51:34PM +0100, Al Viro wrote:
> On Tue, Jul 24, 2007 at 03:39:52PM -0700, bphilips@suse.de wrote:
> > * netdev_pci_remove_one() can replace simple pci device remove
> > functions
> >
> > * devm_alloc_netdev() is like alloc_netdev but allocates memory using devres.
> > alloc_netdev() can be removed once all drivers use devres.
>
> Ewwww... What the hell for? To make sure that we have struct device
> for everything, whether we need it or not? Have you actually read
> through drivers/net? I mean, _really_ read through it, looking for
> ugly cases...
>
> I've done just that several times and I'm sorry, but I would classify
> that project as hopeless. It's way, _way_ more diverse than SATA...
Actually, it's even worse - net_device itself simply *cannot* be
dealt with that way. Its lifetime can indefinitely exceed that
of underlying e.g. PCI device.
^ permalink raw reply
* Re: [PATCH 1/2][RFC] Update net core to use devres.
From: Brandon Philips @ 2007-07-24 23:26 UTC (permalink / raw)
To: Al Viro; +Cc: netdev
In-Reply-To: <20070724230922.GA27392@ftp.linux.org.uk>
On 00:09 Wed 25 Jul 2007, Al Viro wrote:
> On Tue, Jul 24, 2007 at 11:51:34PM +0100, Al Viro wrote:
> > On Tue, Jul 24, 2007 at 03:39:52PM -0700, bphilips@suse.de wrote:
> > > * netdev_pci_remove_one() can replace simple pci device remove
> > > functions
> > >
> > > * devm_alloc_netdev() is like alloc_netdev but allocates memory using devres.
> > > alloc_netdev() can be removed once all drivers use devres.
> >
> > Ewwww... What the hell for? To make sure that we have struct device
> > for everything, whether we need it or not? Have you actually read
> > through drivers/net? I mean, _really_ read through it, looking for
> > ugly cases...
> >
> > I've done just that several times and I'm sorry, but I would classify
> > that project as hopeless. It's way, _way_ more diverse than SATA...
>
> Actually, it's even worse - net_device itself simply *cannot* be
> dealt with that way. Its lifetime can indefinitely exceed that
> of underlying e.g. PCI device.
Could you point me to an example you have in mind?
I quickly searched through a handful of the PCI device drivers and
couldn't find an example where the .remove function didn't do something
to the tune of:
unregister_netdev(dev);
... various un-allocs and cleanup ...
free_netdev(dev)
...
return;
Thank You,
Brandon
^ permalink raw reply
* Re: [PATCH 1/2][RFC] Update net core to use devres.
From: Al Viro @ 2007-07-24 23:30 UTC (permalink / raw)
To: Brandon Philips; +Cc: netdev
In-Reply-To: <20070724232621.GB11350@ifup.org>
On Tue, Jul 24, 2007 at 04:26:21PM -0700, Brandon Philips wrote:
> Could you point me to an example you have in mind?
>
> I quickly searched through a handful of the PCI device drivers and
> couldn't find an example where the .remove function didn't do something
> to the tune of:
>
> unregister_netdev(dev);
> ... various un-allocs and cleanup ...
> free_netdev(dev)
Now find the definition of free_netdev() and read it through, please.
^ permalink raw reply
* Re: 2.6.23-rc1 sky2 boot crash in sky2_mac_intr
From: Michal Piotrowski @ 2007-07-24 23:30 UTC (permalink / raw)
To: Florian Lohoff; +Cc: Stephen Hemminger, linux-kernel, netdev
In-Reply-To: <20070724094042.GA6414@paradigm.rfc822.org>
Hi Florian,
On 24/07/07, Florian Lohoff <flo@rfc822.org> wrote:
> On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
> > The problem is related to power management. The PHY has a number of PCI configuration
> > registers for power control, and the function of these changes based on the version and
> > revision of the chip. The driver does work on older versions of the EC-U, in
> > Fujitsu laptop's, it is just the new rev that is broken.
> >
> > The driver should probably fail smarter (by not loading) if the PHY isn't powered
> > up correctly, but that doesn't help your problem.
> >
> > The vendor has provided me with documentation on many versions
> > of the chip, but I don't have doc's on the lastest revision differences of the EC Ultra,
> > so a proper solution is not easily available. The best method for resolving this would
> > be to first try the vendor driver version of sk98lin and see if that fixes it. If so,
> > then it is easy to change sky2, to match the phy setup in the vendor driver.
> > Another possibility is to look for places in sky2 driver where there are places
> > that compare version/revision.
> >
> > The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 0x88
> > You could also load the windows driver and dump PCI config space (with lspci from
> > cygwin), and see what the settings are there.
> >
> > I am away from my office for a month, and therefore away from any sky2
> > hardware for testing.
>
> I'll try the above and keep you posted. The crash itself seems to be a
> 2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
> which i was running before.
Can you try to figure out what is causing this crash and then use git-bisect?
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* RE: [PATCH 1/2][RFC] Update net core to use devres.
From: Waskiewicz Jr, Peter P @ 2007-07-24 23:42 UTC (permalink / raw)
To: bphilips, netdev
In-Reply-To: <11853167964115-git-send-email-bphilips@suse.de>
> * netdev_pci_remove_one() can replace simple pci device remove
> functions
>
> * devm_alloc_netdev() is like alloc_netdev but allocates
> memory using devres.
> alloc_netdev() can be removed once all drivers use devres.
Please look at the multiqueue network code that is in 2.6.23. It
creates alloc_netdev_mq() for multiqueue network device drivers. If you
want to add this devres feature (which based on the threads, might be
difficult), please make sure you comprehend the multiqueue features.
Thanks,
-PJ Waskiewicz
^ permalink raw reply
* Re: 2.6.20->2.6.21 - networking dies after random time
From: Thomas Gleixner @ 2007-07-25 0:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Marcin ??lusarz, Jarek Poplawski,
Jean-Baptiste Vignaud, linux-kernel, shemminger, linux-net,
netdev, Andrew Morton
In-Reply-To: <20070724200431.GA22190@elte.hu>
On Tue, 2007-07-24 at 22:04 +0200, Ingo Molnar wrote:
> Marcin, could you try the patch below too? [without having any other
> patch applied.] It basically turns the critical section into an irqs-off
> critical section and thus checks whether your problem is related to that
> particular area of code.
>
I read back on this thread and I think the problem is somewhere else:
delayed disable relies on the ability to re-trigger the interrupt in the
case that a real interrupt happens after the software disable was set.
In this case we actually disable the interrupt on the hardware level
_after_ it occurred.
On enable_irq, we need to re-trigger the interrupt. On i386 this relies
on a hardware resend mechanism (send_IPI_self()).
Actually we only need the resend for edge type interrupts. Level type
interrupts come back once enable_irq() re-enables the interrupt line.
I assume that the interrupt in question is level triggered because it is
shared and above the legacy irqs 0-15:
17: 12 IO-APIC-fasteoi eth1, eth0
Looking into the IO_APIC code, the resend via send_IPI_self() happens
unconditionally. So the resend is done for level and edge interrupts.
This makes the problem more mysterious.
The code in question lib8390.c does
disable_irq();
fiddle_with_the_network_card_hardware()
enable_irq();
The fiddle_with_the_network_card_hardware() might cause interrupts,
which are cleared in the same code path again,
Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.
So the difference is that we can get a resend on enable_irq, when an
interrupt happens during the time, where we are in the disabled region.
No idea how this affects the network card, as the code there must be
able to handle interrupts, which are not originated from the card due to
interrupt sharing.
Marcin, can you please try the patch below ? It's just a debugging aid
to gather some more data about that problem.
If the patch fixes the problem, then we should try to disable the resend
mechanism for not edge type irq lines on the irq_chip level (i.e. the
IOAPIC code)
Thanks,
tglx
--- linux-2.6.orig/kernel/irq/resend.c
+++ linux-2.6/kernel/irq/resend.c
@@ -62,6 +62,15 @@ void check_irq_resend(struct irq_desc *desc, unsigned int irq)
*/
desc->chip->enable(irq);
+ /*
+ * Temporary hack to figure out more about the problem, which
+ * is causing the ancient network cards to die.
+ */
+ if (desc->handle_irq != handle_edge_irq) {
+ printk(KERN_DEBUG "Skip resend for irq %u\n", irq);
+ return;
+ }
+
if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
desc->status = (status & ~IRQ_PENDING) | IRQ_REPLAY;
^ permalink raw reply
* Tc filtering: broken 802_3 classifier?
From: Waskiewicz Jr, Peter P @ 2007-07-25 0:19 UTC (permalink / raw)
To: netdev
I've been trying to use tc filtering to filter on ethertype, among other
things in the MAC layer. I'm running into multiple issues, and want to
put this out there in case I'm using the filters wrong, or if there
really is a bug in the filter code (I've stared at most of it today, and
my head hurts).
Here's the scenario. I am running on a recent 2.6.23 GIT tree, and am
using sch_prio with no multiqueue turned on in the qdisc. The network
interface in question is e1000 (no multiqueue).
# tc qdisc add dev eth0 root handle 1: prio
Now to see the flowid's packet counts incrementing, I add explicit
classful qdiscs to the leaves:
# tc qdisc add dev eth0 parent 1:1 handle 10: pfifo
# tc qdisc add dev eth0 parent 1:2 handle 20: pfifo
# tc qdisc add dev eth0 parent 1:3 handle 30: pfifo
Now packet counts can be seen with:
# tc -s qdisc ls dev eth0
I can add a filter for IP for ssh, and it works as intended:
# tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dport
22 0xffff flowid 1:3
This will shove ssh traffic into the 3rd pfifo queue, where by default
it will flow into flowid 1:1. This is good.
Now I add a filter for ethernet (802.3), and things aren't as happy:
# tc filter add dev eth0 protocol 802_3 parent 1: prio 2 u32 match u32
<first 4 bytes of dst mac address> 0xffffffff at 0 match u32 <last 2
bytes of dst mac address> 0xffff0000 at 4 flowid 1:1
This should match the destination MAC address of outgoing packets, and
put it into flowid 1:1. For pings, using the normal priomap, they go
into 1:2, so ping should be a good candidate for seeing if it goes into
1:1. In this case, it does not filter into 1:1.
If I expand this into 8 flows on a multiqueue NIC, using sch_prio or
sch_rr, adding any 802_3 filter to the chain will cause any traffic that
hits the classifier (i.e. no other filters match first) to go into
flowid 1:1, regardless if it actually matches. Remove the 802_3 filter
from the chain, and all filtering starts working again.
I'm trying to get state from the classifier code now when it's running,
but it's a really big mess of black magic. I'm wondering if anyone is
also seeing this behavior, and if they've tried to fix it. If not, I'll
continue to search for a solution, but I'm just polling the community to
see if this is a known issue, or if I'm doing something wrong.
Thanks,
-PJ Waskiewicz
Intel Corporation
peter.p.waskiewicz.jr@intel.com <mailto:peter.p.waskiewicz.jr@intel.com>
^ permalink raw reply
* Re: Tc filtering: broken 802_3 classifier?
From: Patrick McHardy @ 2007-07-25 0:31 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P; +Cc: netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32903484027@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
> [...]
> Now I add a filter for ethernet (802.3), and things aren't as happy:
>
> # tc filter add dev eth0 protocol 802_3 parent 1: prio 2 u32 match u32
> <first 4 bytes of dst mac address> 0xffffffff at 0 match u32 <last 2
> bytes of dst mac address> 0xffff0000 at 4 flowid 1:1
>
> This should match the destination MAC address of outgoing packets, and
> put it into flowid 1:1. For pings, using the normal priomap, they go
> into 1:2, so ping should be a good candidate for seeing if it goes into
> 1:1. In this case, it does not filter into 1:1.
The protocol match is on skb->protocol, so it case of ethernet its
on the ethernet protocol, which is ETH_P_IP or "ip" for IPv4.
^ permalink raw reply
* [PATCH] NET_DMA: remove unused dma_memcpy_to_kernel_iovec
From: Shannon Nelson @ 2007-07-25 0:36 UTC (permalink / raw)
To: netdev, davem; +Cc: viro, christopher.leech, andy.grover, shannon.nelson
(repost - original eaten by vger?)
Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
unreachable and thus unused. The code originally was there to support
in-kernel dma needs, but since it remains unused, we'll pull it out.
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
---
drivers/dma/iovlock.c | 27 ---------------------------
1 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/drivers/dma/iovlock.c b/drivers/dma/iovlock.c
index d637555..e763d72 100644
--- a/drivers/dma/iovlock.c
+++ b/drivers/dma/iovlock.c
@@ -143,29 +143,6 @@ void dma_unpin_iovec_pages(struct dma_pinned_list *pinned_list)
kfree(pinned_list);
}
-static dma_cookie_t dma_memcpy_to_kernel_iovec(struct dma_chan *chan, struct
- iovec *iov, unsigned char *kdata, size_t len)
-{
- dma_cookie_t dma_cookie = 0;
-
- while (len > 0) {
- if (iov->iov_len) {
- int copy = min_t(unsigned int, iov->iov_len, len);
- dma_cookie = dma_async_memcpy_buf_to_buf(
- chan,
- iov->iov_base,
- kdata,
- copy);
- kdata += copy;
- len -= copy;
- iov->iov_len -= copy;
- iov->iov_base += copy;
- }
- iov++;
- }
-
- return dma_cookie;
-}
/*
* We have already pinned down the pages we will be using in the iovecs.
@@ -187,10 +164,6 @@ dma_cookie_t dma_memcpy_to_iovec(struct dma_chan *chan, struct iovec *iov,
if (!chan)
return memcpy_toiovec(iov, kdata, len);
- /* -> kernel copies (e.g. smbfs) */
- if (!pinned_list)
- return dma_memcpy_to_kernel_iovec(chan, iov, kdata, len);
-
iovec_idx = 0;
while (iovec_idx < pinned_list->nr_iovecs) {
struct dma_page_list *page_list;
^ permalink raw reply related
* Re: [FIX] NET: Fix sch_api and sch_prio to properly set and detect the root qdisc
From: Patrick McHardy @ 2007-07-25 0:35 UTC (permalink / raw)
To: PJ Waskiewicz; +Cc: davem, netdev
In-Reply-To: <20070724223346.10658.80645.stgit@localhost.localdomain>
PJ Waskiewicz wrote:
> This is a patch from Patrick McHardy to fix the sch_api code, which I
> went ahead and tested and made a slight fix to. This also includes
> the fix to sch_prio based on Patrick's patch.
>
> The sch->parent handle should contain the parent qdisc ID. When the
> qdisc is the root qdisc (TC_H_ROOT), the parent handle should be the
> value TC_H_ROOT. This fixes sch_api to set this correctly on
> qdisc_create() for both ingress and egress qdiscs.
>
> Change this check in prio_tune() so that only the root qdisc can be
> multiqueue-enabled; use sch->parent instead of sch->handle.
Both look good, thanks.
Acked-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [PATCH] NET_DMA: remove unused dma_memcpy_to_kernel_iovec
From: David Miller @ 2007-07-25 0:37 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, viro, christopher.leech, andy.grover
In-Reply-To: <20070725003606.11018.15141.stgit@localhost.localdomain>
From: Shannon Nelson <shannon.nelson@intel.com>
Date: Tue, 24 Jul 2007 17:36:06 -0700
> (repost - original eaten by vger?)
This one seems to have made it.
> Al Viro pointed out that dma_memcpy_to_kernel_iovec() really was
> unreachable and thus unused. The code originally was there to support
> in-kernel dma needs, but since it remains unused, we'll pull it out.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
This looks OK, unless some objections come up I'll merge this in
during my next round of net fixes to Linus.
^ permalink raw reply
* Re: [PATCH RFX]: napi_struct V3
From: David Miller @ 2007-07-25 0:45 UTC (permalink / raw)
To: rusty; +Cc: netdev, shemminger, jgarzik, hadi
In-Reply-To: <1185258104.1803.223.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Tue, 24 Jul 2007 16:21:43 +1000
> On Mon, 2007-07-23 at 22:47 -0700, David Miller wrote:
> > Any objections?
>
> On the contrary, this looks good.
It turns out the explicit restart logic isn't necessary. On the first
driver I tried to "convert" this became apparent real fast.
The key is what the ->poll() caller does if you don't complete the
NAPI, from net_rx_action():
/* if napi_complete not called, reschedule */
if (test_bit(NAPI_STATE_SCHED, &n->state))
__napi_schedule(n);
Let's look at ep93xx_poll() as it sits in my current tree, which used
to use netif_rx_reschedule():
static int ep93xx_poll(struct napi_struct *napi, int budget)
{
struct ep93xx_priv *ep = container_of(napi, struct ep93xx_priv, napi);
struct net_device *dev = ep->dev;
int rx;
/*
* @@@ Have to stop polling if device is downed while we
* are polling.
*/
rx = ep93xx_rx(dev, 0, budget);
if (rx < budget) {
spin_lock_irq(&ep->rx_lock);
wrl(ep, REG_INTEN, REG_INTEN_TX | REG_INTEN_RX);
if (ep93xx_have_more_rx(ep))
wrl(ep, REG_INTEN, REG_INTEN_TX);
else
netif_rx_complete(dev, napi);
spin_unlock_irq(&ep->rx_lock);
}
return rx;
}
This driver handles TX in it's hardware interrupt handler, and RX
via NAPI. So to NAPI poll it simply disables RX interrupts and
schedules NAPI.
if (status & REG_INTSTS_RX) {
spin_lock(&ep->rx_lock);
if (likely(__netif_rx_schedule_prep(dev, &ep->napi))) {
wrl(ep, REG_INTEN, REG_INTEN_TX);
__netif_rx_schedule(dev, &ep->napi);
}
spin_unlock(&ep->rx_lock);
}
anyways, if after re-enabling RX interrupts it sees some RX
work, it can simply re-disable RX interrupts and leave the NAPI
state alone. And that's how I've coded things above.
The caller will requeue the NAPI instance onto the poll list,
nothing more needs to be done to prevent event loss.
I'm now going to go over the other resched cases and make sure
things can be similarly handled in those drivers as well.
To be honest I'm quite confident this will be the case.
^ permalink raw reply
* Re: [PATCH] Netfilter Kconfig: Expose IPv4/6 connection tracking options by selecting NF_CONNTRACK
From: Patrick McHardy @ 2007-07-25 0:46 UTC (permalink / raw)
To: Al Boldi; +Cc: Sam Ravnborg, netdev, linux-net, David Miller, Andrew Morton
In-Reply-To: <200707242301.42329.a1426z@gawab.com>
Al Boldi wrote:
> Patrick McHardy wrote:
>
>>Al Boldi wrote:
>>
>>>Also, we could leave this as is, and select NF_CONNTRACK_ENABLED instead
>>>of NF_CONNTRACK.
>>
>>I guess so, and that would have to select NF_CONNTRACK.
>
>
> Should I resend, or can you take care of it?
Please resend after testing.
^ permalink raw reply
* Re: [PATCH RFX]: napi_struct V3
From: Rusty Russell @ 2007-07-25 1:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, jgarzik, hadi
In-Reply-To: <20070724.174537.21926733.davem@davemloft.net>
On Tue, 2007-07-24 at 17:45 -0700, David Miller wrote:
> I'm now going to go over the other resched cases and make sure
> things can be similarly handled in those drivers as well.
> To be honest I'm quite confident this will be the case.
If I understand correctly, you're looking at a general model like the
following:
while (more_packets()) { ... netif_receive_skb() }
enable_rx_and_rxnobuf_ints();
/* Lock protects against race w/ rx interrupt re-queueing us */
spin_lock_irq();
if (!more_packets())
netif_rx_complete(dev);
else
/* We'll be scheduled again. */
disable_rx_and_rxnobuff_ints();
spin_unlock_irq();
Seems pretty robust to me. The race is probably pretty unusual, so the
only downside is the locking overhead? Even non-irq-problematic drivers
could use this (ie. virt_net.c probably wants to do it even though
virtio implementation may not have this issue).
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 1/2][RFC] Update net core to use devres.
From: Al Viro @ 2007-07-25 1:23 UTC (permalink / raw)
To: Brandon Philips; +Cc: netdev
In-Reply-To: <20070724233007.GW21668@ftp.linux.org.uk>
On Wed, Jul 25, 2007 at 12:30:07AM +0100, Al Viro wrote:
> On Tue, Jul 24, 2007 at 04:26:21PM -0700, Brandon Philips wrote:
> > Could you point me to an example you have in mind?
> >
> > I quickly searched through a handful of the PCI device drivers and
> > couldn't find an example where the .remove function didn't do something
> > to the tune of:
> >
> > unregister_netdev(dev);
> > ... various un-allocs and cleanup ...
> > free_netdev(dev)
>
> Now find the definition of free_netdev() and read it through, please.
PS: free_netdev() is certainly a bad name for that; the reasons are
mostly historical, since it used to free the damn thing. When that
became impossible (read: previous time net_device has meat device
model; consequences had not been pretty), the patch series from hell
had been big enough without renaming that one on top of everything else.
^ permalink raw reply
* Re: [PATCH RFX]: napi_struct V3
From: David Miller @ 2007-07-25 1:47 UTC (permalink / raw)
To: rusty; +Cc: netdev, shemminger, jgarzik, hadi
In-Reply-To: <1185326149.1803.421.camel@localhost.localdomain>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Wed, 25 Jul 2007 11:15:49 +1000
> If I understand correctly, you're looking at a general model like the
> following:
>
> while (more_packets()) { ... netif_receive_skb() }
>
> enable_rx_and_rxnobuf_ints();
>
> /* Lock protects against race w/ rx interrupt re-queueing us */
> spin_lock_irq();
> if (!more_packets())
> netif_rx_complete(dev);
> else
> /* We'll be scheduled again. */
> disable_rx_and_rxnobuff_ints();
> spin_unlock_irq();
>
> Seems pretty robust to me. The race is probably pretty unusual, so the
> only downside is the locking overhead? Even non-irq-problematic drivers
> could use this (ie. virt_net.c probably wants to do it even though
> virtio implementation may not have this issue).
Yes, interesting cases come up in the existing virtual drivers.
They do no locking at all :-) EHEA is another case, in fact
EHEA doesn't disable interrupts at all.
The reason is that EHEA has several NAPI sources behind one single
hardware interrupt.
That driver's issues were discussed long ago and actually were the
initial impetus for Stephen to cut the first napi_struct patch.
Because of that weird layout EHEA needs special consideration, which I
will get back to.
Anyways, here is how ibmveth.c looks right now in my tree:
static int ibmveth_poll(struct napi_struct *napi, int budget)
{
struct ibmveth_adapter *adapter = container_of(napi, struct ibmveth_adapter, napi);
struct net_device *netdev = adapter->netdev;
int frames_processed = 0;
unsigned long lpar_rc;
do {
struct sk_buff *skb;
if (!ibmveth_rxq_pending_buffer(adapter))
break;
rmb();
if (!ibmveth_rxq_buffer_valid(adapter)) {
...
} else {
...
frames_processed++;
...
}
} while (frames_processed < budget);
ibmveth_replenish_task(adapter);
if (frames_processed < budget) {
/* We think we are done - reenable interrupts,
* then check once more to make sure we are done.
*/
spin_lock_irq(&adapter->poll_lock);
lpar_rc = h_vio_signal(adapter->vdev->unit_address,
VIO_IRQ_ENABLE);
ibmveth_assert(lpar_rc == H_SUCCESS);
if (ibmveth_rxq_pending_buffer(adapter))
lpar_rc = h_vio_signal(adapter->vdev->unit_address,
VIO_IRQ_DISABLE);
else
netif_rx_complete(netdev, napi);
spin_unlock_irq(&adapter->poll_lock);
}
return frames_processed;
}
static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance)
{
struct net_device *netdev = dev_instance;
struct ibmveth_adapter *adapter = netdev->priv;
unsigned long lpar_rc;
spin_lock(&adapter->poll_lock);
if (netif_rx_schedule_prep(netdev, &adapter->napi)) {
lpar_rc = h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
ibmveth_assert(lpar_rc == H_SUCCESS);
__netif_rx_schedule(netdev, &adapter->napi);
}
spin_unlock(&adapter->poll_lock);
return IRQ_HANDLED;
}
A part of me looks at cases like this and almost believes that
the new spinlock is even superfluous. Consider:
1) ->poll() is guarenteed single-threaded wrt. itself
2) NAPI_STATE_SCHED provides implicit synchronization,
it behaves as a lock
However the lock is necessary to synchronize the:
reenable_interrupts();
if (rx_pending())
disable_interrupts();
else
netif_rx_complete(netdev, napi);
sequence.
Any arriving interrupt, up until the moment netif_rx_complete()
is invoked, will fail the netif_rx_schedule_prep() test. So we
could miss a NAPI schedule without the lock.
One thing that's peculiar is that when netif_rx_schedule_prep()
fails, we don't disable interrupts but we also don't clear the
condition that is causing the interrupt to occur.
This seems to suggest to me that we can loop a lot, or even get stuck
completely handling the interrupt forever, when these scenerios
trigger. So at the very least we need a local IRQ disable around
the netif_rx_complete() sequence.
Perhaps the lock is avoidable somehow, who knows :)
^ permalink raw reply
* Re: [PATCH RFX]: napi_struct V3
From: Rusty Russell @ 2007-07-25 2:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, jgarzik, hadi
In-Reply-To: <20070724.184759.111203672.davem@davemloft.net>
On Tue, 2007-07-24 at 18:47 -0700, David Miller wrote:
> One thing that's peculiar is that when netif_rx_schedule_prep()
> fails, we don't disable interrupts but we also don't clear the
> condition that is causing the interrupt to occur.
I think we're ok, but this stuff is tricky.
In the driver in -rc1, I think it will only fail if racing with the
netif_rx_reschedule, which will do the right thing.
In your version, there is only one place where prep can fail (ie.
interrupts are enabled, but netif_rx_complete() hasn't been called):
when ibmveth_poll saw pending buffers and disabled the irq (which has
already been delivered and is spinning on the poll_lock)
In this case, we're ok because the irqs really are disabled now: the
running handler is a relic.
> Perhaps the lock is avoidable somehow, who knows :)
Maybe by adding YA state bit? Hold on, this might get ugly...
Say netif_rx_schedule_prep() sets the MORE_TODO bit (atomically instead
of setting __LINK_STATE_RX_SCHED) if it's going to fail, and
netif_rx_complete() returns 0 if it was set, or 1 if it's OK. Now
callers do:
reenable_interrupts();
if (rx_pending() || !netif_rx_complete(netdev, napi))
disable_interrupts();
I'm going to go absorb some more caffeine before you reply 8)
Rusty.
^ permalink raw reply
* Re: [PATCH 00/10] Implement batching skb API
From: Krishna Kumar2 @ 2007-07-25 2:41 UTC (permalink / raw)
To: hadi
Cc: davem, gaagaan, general, herbert, jagana, jeff, johnpol, kaber,
kumarkr, mcarlson, mchan, netdev, peter.p.waskiewicz.jr, rdreier,
rick.jones2, Robert.Olsson, sri, tgraf, xma
In-Reply-To: <1185305300.26013.152.camel@localhost>
Jamal,
This is silly. I am not responding to this type of presumptuous and
insulting mails.
Regards,
- KK
J Hadi Salim <j.hadi123@gmail.com> wrote on 07/25/2007 12:58:20 AM:
> KK,
>
> On Tue, 2007-24-07 at 09:14 +0530, Krishna Kumar2 wrote:
>
> >
> > J Hadi Salim <j.hadi123@gmail.com> wrote on 07/23/2007 06:02:01 PM:
>
>
> > Actually you have not sent netperf results with prep and without prep.
>
> My results were based on pktgen (which i explained as testing the
> driver). I think depending on netperf without further analysis is
> simplistic. It was like me doing forwarding tests on these patches.
>
> > > So _which_ non-LLTX driver doesnt do that? ;->
> >
> > I have no idea since I haven't looked at all drivers. Can you tell
which
> > all non-LLTX drivers does that ? I stated this as the sole criterea.
>
> The few i have peeked at all do it. I also think the e1000 should be
> converted to be non-LLTX. The rest of netdev is screaming to kill LLTX.
>
> > > tun driver doesnt use it either - but i doubt that makes it "bloat"
> >
> > Adding extra code that is currently not usable (esp from a submission
> > point) is bloat.
>
> So far i have converted 3 drivers, 1 of them doesnt use it. Two more
> driver conversions are on the way, they will both use it. How is this
> bloat again?
> A few emails back you said if only IPOIB can use batching then thats
> good enough justification.
>
> > > You waltz in, have the luxury of looking at my code, presentations,
many
> > > discussions with me etc ...
> >
> > "luxury" ?
> > I had implemented the entire thing even before knowing that you
> > are working on something similar! and I had sent the first proposal to
> > netdev,
>
> I saw your patch at the end of may (or at least 2 weeks after you said
> it existed). That patch has very little resemblance to what you just
> posted conceptwise or codewise. I could post it if you would give me
> permission.
>
> > *after* which you told that you have your own code and presentations
(which
> > I had never seen earlier - I joined netdev a few months back, earlier I
was
> > working on RDMA, Infiniband as you know).
>
> I am gonna assume you didnt know of my work - which i have been making
> public for about 3 years. Infact i talked about this topic when i
> visited your office in 2006 on a day you were not present, so it is
> plausible you didnt hear of it.
>
> > And it didn't give me any great
> > ideas either, remember I had posted results for E1000 at the time of
> > sending the proposals.
>
> In mid-June you sent me a series of patches which included anything from
> changing variable names to combining qdisc_restart and about everything
> i referred to as being "cosmetic differences" in your posted patches. I
> took two of those and incorporated them in. One was an "XXX" in my code
> already to allocate the dev->blist
> (Commit: bb4464c5f67e2a69ffb233fcf07aede8657e4f63).
> The other one was a mechanical removal of the blist being passed
> (Commit: 0e9959e5ee6f6d46747c97ca8edc91b3eefa0757).
> Some of the others i asked you to defer. For example, the reason i gave
> you for not merging any qdisc_restart_combine changes is because i was
> waiting for Dave to swallow the qdisc_restart changes i made; otherwise
> maintainance becomes extremely painful for me.
> Sridhar actually provided a lot more valuable comments and fixes but has
> not planted a flag on behalf of the queen of spain like you did.
>
> > However I do give credit in my proposal to you for what
> > ideas that your provided (without actual code), and the same I did for
other
> > people who did the same, like Dave, Sridhar. BTW, you too had
discussions with me,
> > and I sent some patches to improve your code too,
>
> I incorporated two of your patches and asked for deferal of others.
> These patches have now shown up in what you claim as "the difference". I
> just call them "cosmetic difference" not to downplay the importance of
> having an ethtool interface but because they do not make batching
> perform any better. The real differences are those two items. I am
> suprised you havent cannibalized those changes as well. I thought you
> renamed them to something else; according to your posting:
> "This patch will work with drivers updated by Jamal, Matt & Michael Chan
> with minor modifications - rename xmit_win to xmit_slots & rename batch
> handler". Or maybe thats a "future plan" you have in mind?
>
> > so it looks like a two
> > way street to me (and that is how open source works and should).
>
> Open source is a lot more transparent than that.
>
> You posted a question, which was part of your research. I responded and
> told you i have patches; you asked me for them and i promptly ported
> them from pre-2.6.18 to the latest kernel at the time.
>
> The nature of this batching work is one of performance. So numbers are
> important. If you had some strong disagreements on something in the
> architecture, then it would be of great value to explain it in a
> technical detail - and more importantly to provide some numbers to say
> why it is a bad idea. You get numbers by running some tests.
> You did none of the above. Your effort has been to produce "your patch"
> for whatever reasons. This would not have been problematic to me if it
> actually was based within reasons of optimization because the end goal
> would have been achieved.
>
> I have deleted the rest of the email because it goes back and forth on
> the same points.
>
> I am gonna continue work on the current tree i have. I will put more
> time when i get back next week (and hopefully no travel right after).
> I will upgrade to Daves tree later when i get the two new drivers in. I
> am probably gonna hold on until the new NAPI stuff settles in first. You
> are welcome to submit the ipoib changes in. You are also welcome to
> co-author with me but you will have to work for it this time.
>
> cheers,
> jamal
>
^ 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