* workaround large MTU and N-order allocation failures
From: Dan Aloni @ 2005-09-18 14:35 UTC (permalink / raw)
To: Linux Kernel List, netdev; +Cc: Nick Piggin
Hello,
Is there currently a workaround available for handling large MTU
(larger than 1 page, even 2-order) in the Linux network stack?
The problem with large MTU is external memory fragmentation in
the buddy system following high workload, causing alloc_skb() to
fail.
I'm interested in patches for both 2.4 and 2.6 kernels.
Thanks,
--
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net
^ permalink raw reply
* [PATCH 3/2] forcedeth: Compile fix forcedeth 0.44
From: Manfred Spraul @ 2005-09-18 14:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ayaz Abdulla, Netdev
[-- Attachment #1: Type: text/plain, Size: 229 bytes --]
Hi,
forcedeth-0.44 contains a spurious ; in nv_release_txskb. gcc-4 compiles
it with a warning, older compilers might reject it.
The attached onliner fixes that, sorry.
Signed-off-By: Manfred Spraul <manfred@colorfullife.com>
[-- Attachment #2: patch-forcedeth-044a-compilefix --]
[-- Type: text/plain, Size: 521 bytes --]
--- 2.6/drivers/net/forcedeth.c 2005-09-18 16:12:10.000000000 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-09-18 16:14:19.000000000 +0200
@@ -923,7 +923,7 @@ static int nv_init_ring(struct net_devic
static void nv_release_txskb(struct net_device *dev, unsigned int skbnr)
{
struct fe_priv *np = get_nvpriv(dev);
- struct sk_buff *skb = np->tx_skbuff[skbnr];;
+ struct sk_buff *skb = np->tx_skbuff[skbnr];
unsigned int j, entry, fragments;
dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n",
^ permalink raw reply
* [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Manfred Spraul @ 2005-09-18 14:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, Ayaz Abdulla
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
The attached patch adds scatter gather and segmentation offload support
into forcedeth driver.
This patch has been tested by NVIDIA and reviewed by Manfred.
Notes:
- Manfred mentioned that mapping of pages could take time and should not
be under spinlock for performance reasons
- During testing with netperf, I have noticed a connection running
segmentation offload gets "unoffloaded" by the kernel due to possible
retransmissions.
Thanks,
Ayaz
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-By: Manfred Spraul <manfred@colorfullife.com>
[-- Attachment #2: patch-forcedeth-044-sg-segmentation --]
[-- Type: text/plain, Size: 9898 bytes --]
--- orig-2.6/drivers/net/forcedeth.c 2005-09-06 11:54:41.000000000 -0700
+++ 2.6/drivers/net/forcedeth.c 2005-09-06 13:52:50.000000000 -0700
@@ -96,6 +96,7 @@
* 0.42: 06 Aug 2005: Fix lack of link speed initialization
* in the second (and later) nv_open call
* 0.43: 10 Aug 2005: Add support for tx checksum.
+ * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -107,7 +108,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.43"
+#define FORCEDETH_VERSION "0.44"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -340,6 +341,8 @@
/* error and valid are the same for both */
#define NV_TX2_ERROR (1<<30)
#define NV_TX2_VALID (1<<31)
+#define NV_TX2_TSO (1<<28)
+#define NV_TX2_TSO_SHIFT 14
#define NV_TX2_CHECKSUM_L3 (1<<27)
#define NV_TX2_CHECKSUM_L4 (1<<26)
@@ -901,11 +904,13 @@
int i;
np->next_tx = np->nic_tx = 0;
- for (i = 0; i < TX_RING; i++)
+ for (i = 0; i < TX_RING; i++) {
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
np->tx_ring.orig[i].FlagLen = 0;
else
np->tx_ring.ex[i].FlagLen = 0;
+ np->tx_skbuff[i] = NULL;
+ }
}
static int nv_init_ring(struct net_device *dev)
@@ -915,21 +920,44 @@
return nv_alloc_rx(dev);
}
+static void nv_release_txskb(struct net_device *dev, unsigned int skbnr)
+{
+ struct fe_priv *np = get_nvpriv(dev);
+ struct sk_buff *skb = np->tx_skbuff[skbnr];;
+ unsigned int j, entry, fragments;
+
+ dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n",
+ dev->name, skbnr, np->tx_skbuff[skbnr]);
+
+ entry = skbnr;
+ if ((fragments = skb_shinfo(skb)->nr_frags) != 0) {
+ for (j = fragments; j >= 1; j--) {
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[j-1];
+ pci_unmap_page(np->pci_dev, np->tx_dma[entry],
+ frag->size,
+ PCI_DMA_TODEVICE);
+ entry = (entry - 1) % TX_RING;
+ }
+ }
+ pci_unmap_single(np->pci_dev, np->tx_dma[entry],
+ skb->len - skb->data_len,
+ PCI_DMA_TODEVICE);
+ dev_kfree_skb_irq(skb);
+ np->tx_skbuff[skbnr] = NULL;
+}
+
static void nv_drain_tx(struct net_device *dev)
{
struct fe_priv *np = get_nvpriv(dev);
- int i;
+ unsigned int i;
+
for (i = 0; i < TX_RING; i++) {
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
np->tx_ring.orig[i].FlagLen = 0;
else
np->tx_ring.ex[i].FlagLen = 0;
if (np->tx_skbuff[i]) {
- pci_unmap_single(np->pci_dev, np->tx_dma[i],
- np->tx_skbuff[i]->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb(np->tx_skbuff[i]);
- np->tx_skbuff[i] = NULL;
+ nv_release_txskb(dev, i);
np->stats.tx_dropped++;
}
}
@@ -968,28 +996,69 @@
static int nv_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fe_priv *np = get_nvpriv(dev);
- int nr = np->next_tx % TX_RING;
- u32 tx_checksum = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0);
+ u32 tx_flags_extra = (np->desc_ver == DESC_VER_1 ? NV_TX_LASTPACKET : NV_TX2_LASTPACKET);
+ unsigned int fragments = skb_shinfo(skb)->nr_frags;
+ unsigned int nr = (np->next_tx + fragments) % TX_RING;
+ unsigned int i;
+
+ spin_lock_irq(&np->lock);
+ wmb();
+
+ if ((np->next_tx - np->nic_tx + fragments) > TX_LIMIT_STOP) {
+ spin_unlock_irq(&np->lock);
+ netif_stop_queue(dev);
+ return 1;
+ }
np->tx_skbuff[nr] = skb;
- np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len,
- PCI_DMA_TODEVICE);
+
+ if (fragments) {
+ dprintk(KERN_DEBUG "%s: nv_start_xmit: buffer contains %d fragments\n", dev->name, fragments);
+ /* setup descriptors in reverse order */
+ for (i = fragments; i >= 1; i--) {
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i-1];
+ np->tx_dma[nr] = pci_map_page(np->pci_dev, frag->page, frag->page_offset, frag->size,
+ PCI_DMA_TODEVICE);
- if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
+ if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+ np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
+ np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra);
+ } else {
+ np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32;
+ np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF;
+ np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra);
+ }
+
+ nr = (nr - 1) % TX_RING;
+
+ if (np->desc_ver == DESC_VER_1)
+ tx_flags_extra &= ~NV_TX_LASTPACKET;
+ else
+ tx_flags_extra &= ~NV_TX2_LASTPACKET;
+ }
+ }
+
+#ifdef NETIF_F_TSO
+ if (skb_shinfo(skb)->tso_size)
+ tx_flags_extra |= NV_TX2_TSO | (skb_shinfo(skb)->tso_size << NV_TX2_TSO_SHIFT);
+ else
+#endif
+ tx_flags_extra |= (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0);
+
+ np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len-skb->data_len,
+ PCI_DMA_TODEVICE);
+
+ if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]);
- else {
+ np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra);
+ } else {
np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32;
np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF;
- }
+ np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra);
+ }
- spin_lock_irq(&np->lock);
- wmb();
- if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
- np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum);
- else
- np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum);
- dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission\n",
- dev->name, np->next_tx);
+ dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission. tx_flags_extra: %x\n",
+ dev->name, np->next_tx, tx_flags_extra);
{
int j;
for (j=0; j<64; j++) {
@@ -1000,11 +1069,9 @@
dprintk("\n");
}
- np->next_tx++;
+ np->next_tx += 1 + fragments;
dev->trans_start = jiffies;
- if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP)
- netif_stop_queue(dev);
spin_unlock_irq(&np->lock);
writel(NVREG_TXRXCTL_KICK|np->txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl);
pci_push(get_hwbase(dev));
@@ -1020,7 +1087,8 @@
{
struct fe_priv *np = get_nvpriv(dev);
u32 Flags;
- int i;
+ unsigned int i;
+ struct sk_buff *skb;
while (np->nic_tx != np->next_tx) {
i = np->nic_tx % TX_RING;
@@ -1035,35 +1103,38 @@
if (Flags & NV_TX_VALID)
break;
if (np->desc_ver == DESC_VER_1) {
- if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION|
- NV_TX_UNDERFLOW|NV_TX_ERROR)) {
- if (Flags & NV_TX_UNDERFLOW)
- np->stats.tx_fifo_errors++;
- if (Flags & NV_TX_CARRIERLOST)
- np->stats.tx_carrier_errors++;
- np->stats.tx_errors++;
- } else {
- np->stats.tx_packets++;
- np->stats.tx_bytes += np->tx_skbuff[i]->len;
+ if (Flags & NV_TX_LASTPACKET) {
+ skb = np->tx_skbuff[i];
+ if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION|
+ NV_TX_UNDERFLOW|NV_TX_ERROR)) {
+ if (Flags & NV_TX_UNDERFLOW)
+ np->stats.tx_fifo_errors++;
+ if (Flags & NV_TX_CARRIERLOST)
+ np->stats.tx_carrier_errors++;
+ np->stats.tx_errors++;
+ } else {
+ np->stats.tx_packets++;
+ np->stats.tx_bytes += skb->len;
+ }
+ nv_release_txskb(dev, i);
}
} else {
- if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION|
- NV_TX2_UNDERFLOW|NV_TX2_ERROR)) {
- if (Flags & NV_TX2_UNDERFLOW)
- np->stats.tx_fifo_errors++;
- if (Flags & NV_TX2_CARRIERLOST)
- np->stats.tx_carrier_errors++;
- np->stats.tx_errors++;
- } else {
- np->stats.tx_packets++;
- np->stats.tx_bytes += np->tx_skbuff[i]->len;
+ if (Flags & NV_TX2_LASTPACKET) {
+ skb = np->tx_skbuff[i];
+ if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION|
+ NV_TX2_UNDERFLOW|NV_TX2_ERROR)) {
+ if (Flags & NV_TX2_UNDERFLOW)
+ np->stats.tx_fifo_errors++;
+ if (Flags & NV_TX2_CARRIERLOST)
+ np->stats.tx_carrier_errors++;
+ np->stats.tx_errors++;
+ } else {
+ np->stats.tx_packets++;
+ np->stats.tx_bytes += skb->len;
+ }
+ nv_release_txskb(dev, i);
}
}
- pci_unmap_single(np->pci_dev, np->tx_dma[i],
- np->tx_skbuff[i]->len,
- PCI_DMA_TODEVICE);
- dev_kfree_skb_irq(np->tx_skbuff[i]);
- np->tx_skbuff[i] = NULL;
np->nic_tx++;
}
if (np->next_tx - np->nic_tx < TX_LIMIT_START)
@@ -2322,6 +2393,8 @@
if (pci_set_dma_mask(pci_dev, 0x0000007fffffffffULL)) {
printk(KERN_INFO "forcedeth: 64-bit DMA failed, using 32-bit addressing for device %s.\n",
pci_name(pci_dev));
+ } else {
+ dev->features |= NETIF_F_HIGHDMA;
}
np->txrxctl_bits = NVREG_TXRXCTL_DESC_3;
} else if (id->driver_data & DEV_HAS_LARGEDESC) {
@@ -2340,8 +2413,11 @@
if (id->driver_data & DEV_HAS_CHECKSUM) {
np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK;
- dev->features |= NETIF_F_HW_CSUM;
- }
+ dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
+#ifdef NETIF_F_TSO
+ dev->features |= NETIF_F_TSO;
+#endif
+ }
err = -ENOMEM;
np->base = ioremap(addr, NV_PCI_REGSZ);
@@ -2420,9 +2496,9 @@
np->wolenabled = 0;
if (np->desc_ver == DESC_VER_1) {
- np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID;
+ np->tx_flags = NV_TX_VALID;
} else {
- np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID;
+ np->tx_flags = NV_TX2_VALID;
}
np->irqmask = NVREG_IRQMASK_WANTED;
if (id->driver_data & DEV_NEED_TIMERIRQ)
^ permalink raw reply
* [PATCH 1/2] forcedeth: Add hardware tx checksum support
From: Manfred Spraul @ 2005-09-18 14:01 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, Ayaz Abdulla
[-- Attachment #1: Type: text/plain, Size: 295 bytes --]
Recent forcedeth nics support checksum offloading for tx.
The attached patch, written by Ayaz Abdulla, adds the support to the driver.
It also cleans up the handling of the three dma ring entry formats that
are supported by the driver.
Signed-off-By: Manfred Spraul <manfred@colorfullife.com>
[-- Attachment #2: patch-forcedeth-043-txchecksum --]
[-- Type: text/plain, Size: 9294 bytes --]
--- orig-2.6/drivers/net/forcedeth.c 2005-09-06 11:46:05.000000000 -0700
+++ 2.6/drivers/net/forcedeth.c 2005-09-06 11:45:15.000000000 -0700
@@ -95,6 +95,7 @@
* of nv_remove
* 0.42: 06 Aug 2005: Fix lack of link speed initialization
* in the second (and later) nv_open call
+ * 0.43: 10 Aug 2005: Add support for tx checksum.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -106,7 +107,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.41"
+#define FORCEDETH_VERSION "0.43"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -145,6 +146,7 @@
#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the timer irq */
#define DEV_HAS_LARGEDESC 0x0004 /* device supports jumbo frames and needs packet format 2 */
#define DEV_HAS_HIGH_DMA 0x0008 /* device supports 64bit dma */
+#define DEV_HAS_CHECKSUM 0x0010 /* device supports tx and rx checksum offloads */
enum {
NvRegIrqStatus = 0x000,
@@ -241,6 +243,9 @@
#define NVREG_TXRXCTL_IDLE 0x0008
#define NVREG_TXRXCTL_RESET 0x0010
#define NVREG_TXRXCTL_RXCHECK 0x0400
+#define NVREG_TXRXCTL_DESC_1 0
+#define NVREG_TXRXCTL_DESC_2 0x02100
+#define NVREG_TXRXCTL_DESC_3 0x02200
NvRegMIIStatus = 0x180,
#define NVREG_MIISTAT_ERROR 0x0001
#define NVREG_MIISTAT_LINKCHANGE 0x0008
@@ -335,6 +340,8 @@
/* error and valid are the same for both */
#define NV_TX2_ERROR (1<<30)
#define NV_TX2_VALID (1<<31)
+#define NV_TX2_CHECKSUM_L3 (1<<27)
+#define NV_TX2_CHECKSUM_L4 (1<<26)
#define NV_RX_DESCRIPTORVALID (1<<16)
#define NV_RX_MISSEDFRAME (1<<17)
@@ -417,14 +424,14 @@
/*
* desc_ver values:
- * This field has two purposes:
- * - Newer nics uses a different ring layout. The layout is selected by
- * comparing np->desc_ver with DESC_VER_xy.
- * - It contains bits that are forced on when writing to NvRegTxRxControl.
+ * The nic supports three different descriptor types:
+ * - DESC_VER_1: Original
+ * - DESC_VER_2: support for jumbo frames.
+ * - DESC_VER_3: 64-bit format.
*/
-#define DESC_VER_1 0x0
-#define DESC_VER_2 (0x02100|NVREG_TXRXCTL_RXCHECK)
-#define DESC_VER_3 (0x02200|NVREG_TXRXCTL_RXCHECK)
+#define DESC_VER_1 1
+#define DESC_VER_2 2
+#define DESC_VER_3 3
/* PHY defines */
#define PHY_OUI_MARVELL 0x5043
@@ -491,6 +498,7 @@
u32 orig_mac[2];
u32 irqmask;
u32 desc_ver;
+ u32 txrxctl_bits;
void __iomem *base;
@@ -786,10 +794,10 @@
u8 __iomem *base = get_hwbase(dev);
dprintk(KERN_DEBUG "%s: nv_txrx_reset\n", dev->name);
- writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET | np->desc_ver, base + NvRegTxRxControl);
+ writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET | np->txrxctl_bits, base + NvRegTxRxControl);
pci_push(base);
udelay(NV_TXRX_RESET_DELAY);
- writel(NVREG_TXRXCTL_BIT2 | np->desc_ver, base + NvRegTxRxControl);
+ writel(NVREG_TXRXCTL_BIT2 | np->txrxctl_bits, base + NvRegTxRxControl);
pci_push(base);
}
@@ -961,6 +969,7 @@
{
struct fe_priv *np = get_nvpriv(dev);
int nr = np->next_tx % TX_RING;
+ u32 tx_checksum = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0);
np->tx_skbuff[nr] = skb;
np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len,
@@ -976,10 +985,10 @@
spin_lock_irq(&np->lock);
wmb();
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
- np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags );
+ np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum);
else
- np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags );
- dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n",
+ np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum);
+ dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission\n",
dev->name, np->next_tx);
{
int j;
@@ -997,7 +1006,7 @@
if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP)
netif_stop_queue(dev);
spin_unlock_irq(&np->lock);
- writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl);
+ writel(NVREG_TXRXCTL_KICK|np->txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl);
pci_push(get_hwbase(dev));
return 0;
}
@@ -1408,7 +1417,7 @@
writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT),
base + NvRegRingSizes);
pci_push(base);
- writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl);
+ writel(NVREG_TXRXCTL_KICK|np->txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl);
pci_push(base);
/* restart rx engine */
@@ -2114,9 +2123,9 @@
/* 5) continue setup */
writel(np->linkspeed, base + NvRegLinkSpeed);
writel(NVREG_UNKSETUP3_VAL1, base + NvRegUnknownSetupReg3);
- writel(np->desc_ver, base + NvRegTxRxControl);
+ writel(np->txrxctl_bits, base + NvRegTxRxControl);
pci_push(base);
- writel(NVREG_TXRXCTL_BIT1|np->desc_ver, base + NvRegTxRxControl);
+ writel(NVREG_TXRXCTL_BIT1|np->txrxctl_bits, base + NvRegTxRxControl);
reg_delay(dev, NvRegUnknownSetupReg5, NVREG_UNKSETUP5_BIT31, NVREG_UNKSETUP5_BIT31,
NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX,
KERN_INFO "open: SetupReg5, Bit 31 remained off\n");
@@ -2314,18 +2323,26 @@
printk(KERN_INFO "forcedeth: 64-bit DMA failed, using 32-bit addressing for device %s.\n",
pci_name(pci_dev));
}
+ np->txrxctl_bits = NVREG_TXRXCTL_DESC_3;
} else if (id->driver_data & DEV_HAS_LARGEDESC) {
/* packet format 2: supports jumbo frames */
np->desc_ver = DESC_VER_2;
+ np->txrxctl_bits = NVREG_TXRXCTL_DESC_2;
} else {
/* original packet format */
np->desc_ver = DESC_VER_1;
+ np->txrxctl_bits = NVREG_TXRXCTL_DESC_1;
}
np->pkt_limit = NV_PKTLIMIT_1;
if (id->driver_data & DEV_HAS_LARGEDESC)
np->pkt_limit = NV_PKTLIMIT_2;
+ if (id->driver_data & DEV_HAS_CHECKSUM) {
+ np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK;
+ dev->features |= NETIF_F_HW_CSUM;
+ }
+
err = -ENOMEM;
np->base = ioremap(addr, NV_PCI_REGSZ);
if (!np->base)
@@ -2525,35 +2542,35 @@
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_4),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_5),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_6),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_7),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM,
},
{ /* CK804 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_8),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{ /* CK804 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_9),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{ /* MCP04 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_10),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{ /* MCP04 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_11),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{ /* MCP51 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_12),
@@ -2565,11 +2582,11 @@
},
{ /* MCP55 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_14),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{ /* MCP55 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_15),
- .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_HIGH_DMA,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC|DEV_HAS_CHECKSUM|DEV_HAS_HIGH_DMA,
},
{0,},
};
^ permalink raw reply
* Re: [PATCH 2/2] netfilter Kconfig whitespace cleanup
From: Harald Welte @ 2005-09-18 13:30 UTC (permalink / raw)
To: David S. Miller; +Cc: acme, netdev, netfilter-devel
In-Reply-To: <20050918.003450.118470112.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Sun, Sep 18, 2005 at 12:34:50AM -0700, David S. Miller wrote:
> From: Harald Welte <laforge@netfilter.org>
> Date: Sat, 17 Sep 2005 18:17:26 +0200
>
> > [NETFILTER] Kconfig whitespace cleanup
> >
> > Signed-off-by: Harald Welte <laforge@netfilter.org>
>
> I got some rejects, although I can't figure out why.
> Can you try rediffing against my current net-2.6 tree?
Sorry for the confusion, your tree already has the tabs (no spaces). So
let's forget about this.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] netfilter Kconfig whitespace cleanup
From: David S. Miller @ 2005-09-18 7:34 UTC (permalink / raw)
To: laforge; +Cc: acme, netdev, netfilter-devel
In-Reply-To: <20050917161726.GC8413@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Sat, 17 Sep 2005 18:17:26 +0200
> [NETFILTER] Kconfig whitespace cleanup
>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
I got some rejects, although I can't figure out why.
Can you try rediffing against my current net-2.6 tree?
Thanks a lot!
^ permalink raw reply
* Re: [PATCH 1/2] netfilter Kconfig dependency fix
From: David S. Miller @ 2005-09-18 7:34 UTC (permalink / raw)
To: laforge; +Cc: acme, netdev, netfilter-devel
In-Reply-To: <20050917161639.GB8413@sunbeam.de.gnumonks.org>
From: Harald Welte <laforge@netfilter.org>
Date: Sat, 17 Sep 2005 18:16:40 +0200
> [NETFILTER] Solve Kconfig dependency problem
>
> As suggested by Roman Zippel.
>
> Signed-off-by: Harald Welte <laforge@netfilter.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] bond_main.c: fix device deregistration in init exception path
From: David S. Miller @ 2005-09-18 7:25 UTC (permalink / raw)
To: akpm; +Cc: fmalita, linux-kernel, ctindel, fubar, netdev
In-Reply-To: <20050917233224.2d4b3652.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Sat, 17 Sep 2005 23:32:24 -0700
> The fix is solid enough, although a better comment is needed. Let's
> let Dave decide whether that was a sane thing to go BUG over..
The fix is fine and so is the BUG() check.
Usually, you're supposed to make sure that the very last thing
you do is register_netdev(), and that all possible errors are
possible only before that call.
And that's what BOND basically does, except that it must register
multiple devices in a loop and therefore cannot follow that rule
precisely.
So I've added the patch to my tree, it's fine to do this for a
special case usage like this one.
^ permalink raw reply
* Re: [PATCH] bond_main.c: fix device deregistration in init exception path
From: Andrew Morton @ 2005-09-18 6:32 UTC (permalink / raw)
To: Florin Malita; +Cc: linux-kernel, ctindel, fubar, David S. Miller, netdev
In-Reply-To: <432D0612.7070408@gmail.com>
Florin Malita <fmalita@gmail.com> wrote:
>
> User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
Your MUA is converting tabs to spaces.
> bond_init() is not releasing rtnl_sem after register_netdevice() and
> before calling unregister_netdevice() (from bond_free_all()) in the
> exception path. As the device registration is not completed
> (dev->reg_state == NETREG_REGISTERING), the call to
> unregister_netdevice() triggers BUG_ON(dev->reg_state != NETREG_REGISTERED).
>
> Signed-off-by: Florin Malita <fmalita@gmail.com>
> ----
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -5039,6 +5039,10 @@ static int __init bonding_init(void)
> return 0;
>
> out_err:
> + /* give register_netdevice() a chance to complete */
> + rtnl_unlock();
> + rtnl_lock();
> +
> /* free and unregister all bonds that were successfully added */
> bond_free_all();
OK, so the bonding devices which were registered are now in state
NETREG_REGISTERING and we need to run netdev_run_todo() to flip them into
state NETREG_REGISTERED. If we don't do that,
bond_free_all()->unregister_netdevice() will go BUG.
The fix is solid enough, although a better comment is needed. Let's let
Dave decide whether that was a sane thing to go BUG over..
From: Florin Malita <fmalita@gmail.com>
bond_init() is not releasing rtnl_sem after register_netdevice() and before
calling unregister_netdevice() (from bond_free_all()) in the exception
path. As the device registration is not completed (dev->reg_state ==
NETREG_REGISTERING), the call to unregister_netdevice() triggers
BUG_ON(dev->reg_state != NETREG_REGISTERED).
Signed-off-by: Florin Malita <fmalita@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/bonding/bond_main.c | 8 ++++++++
1 files changed, 8 insertions(+)
diff -puN drivers/net/bonding/bond_main.c~bond_mainc-fix-device-deregistration-in-init-exception drivers/net/bonding/bond_main.c
--- devel/drivers/net/bonding/bond_main.c~bond_mainc-fix-device-deregistration-in-init-exception 2005-09-17 23:18:38.000000000 -0700
+++ devel-akpm/drivers/net/bonding/bond_main.c 2005-09-17 23:31:02.000000000 -0700
@@ -5039,6 +5039,14 @@ static int __init bonding_init(void)
return 0;
out_err:
+ /*
+ * rtnl_unlock() will run netdev_run_todo(), putting the
+ * thus-far-registered bonding devices into a state which
+ * unregigister_netdevice() will accept
+ */
+ rtnl_unlock();
+ rtnl_lock();
+
/* free and unregister all bonds that were successfully added */
bond_free_all();
_
^ permalink raw reply
* [PATCH 2/2] netfilter Kconfig whitespace cleanup
From: Harald Welte @ 2005-09-17 16:17 UTC (permalink / raw)
To: David Miller
Cc: Arnaldo Carvalho de Melo, Linux Netdev List,
Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
Hi Dave, please apply.
[NETFILTER] Kconfig whitespace cleanup
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 49d4c50fa9b5ee5a718c2a38e28b6dd99fd65c62
tree d06a6a7421369f5e63e6ce7130ab11e9202471ce
parent 95ef9808bc0702757a40886aed48a6fc03aee47b
author Harald Welte <laforge@netfilter.org> Sa, 17 Sep 2005 17:24:18 +0200
committer Harald Welte <laforge@netfilter.org> Sa, 17 Sep 2005 17:24:18 +0200
net/ipv4/netfilter/Kconfig | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -52,11 +52,11 @@ config IP_NF_CONNTRACK_EVENTS
IF unsure, say `N'.
config IP_NF_CONNTRACK_NETLINK
- tristate 'Connection tracking netlink interface'
- depends on IP_NF_CONNTRACK && NETFILTER_NETLINK
+ tristate 'Connection tracking netlink interface'
+ depends on IP_NF_CONNTRACK && NETFILTER_NETLINK
depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m
- help
- This option enables support for a netlink-based userspace interface
+ help
+ This option enables support for a netlink-based userspace interface
config IP_NF_CT_PROTO_SCTP
@@ -192,8 +192,8 @@ config IP_NF_MATCH_PKTTYPE
tristate "Packet type match support"
depends on IP_NF_IPTABLES
help
- Packet type matching allows you to match a packet by
- its "class", eg. BROADCAST, MULTICAST, ...
+ Packet type matching allows you to match a packet by
+ its "class", eg. BROADCAST, MULTICAST, ...
Typical usage:
iptables -A INPUT -m pkttype --pkt-type broadcast -j LOG
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] netfilter Kconfig dependency fix
From: Harald Welte @ 2005-09-17 16:16 UTC (permalink / raw)
To: David Miller
Cc: Arnaldo Carvalho de Melo, Linux Netdev List,
Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Hi Dave, please apply.
[NETFILTER] Solve Kconfig dependency problem
As suggested by Roman Zippel.
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit 95ef9808bc0702757a40886aed48a6fc03aee47b
tree 03b0cca73e6c7f686702c52291e9eb786bb8f02a
parent 1d21ab174ffeba8e709966dc60e57524553adb84
author Harald Welte <laforge@netfilter.org> Sa, 17 Sep 2005 17:22:53 +0200
committer Harald Welte <laforge@netfilter.org> Sa, 17 Sep 2005 17:22:53 +0200
net/ipv4/netfilter/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/netfilter/Kconfig b/net/ipv4/netfilter/Kconfig
--- a/net/ipv4/netfilter/Kconfig
+++ b/net/ipv4/netfilter/Kconfig
@@ -8,7 +8,6 @@ menu "IP: Netfilter Configuration"
# connection tracking, helpers and protocols
config IP_NF_CONNTRACK
tristate "Connection tracking (required for masq/NAT)"
- select NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n
---help---
Connection tracking keeps a record of what packets have passed
through your machine, in order to figure out how they are related
@@ -55,8 +54,7 @@ config IP_NF_CONNTRACK_EVENTS
config IP_NF_CONNTRACK_NETLINK
tristate 'Connection tracking netlink interface'
depends on IP_NF_CONNTRACK && NETFILTER_NETLINK
- default IP_NF_CONNTRACK if NETFILTER_NETLINK=y
- default m if NETFILTER_NETLINK=m
+ depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m
help
This option enables support for a netlink-based userspace interface
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [HELP] netfilter Kconfig dependency nightmare
From: Arnaldo Carvalho de Melo @ 2005-09-17 15:32 UTC (permalink / raw)
To: Harald Welte, Roman Zippel, Arnaldo Carvalho de Melo,
Netfilter Development Mailinglist, Linux Netdev List,
Linux Kernel Mailinglist
In-Reply-To: <20050917152931.GA8413@sunbeam.de.gnumonks.org>
On 9/17/05, Harald Welte <laforge@netfilter.org> wrote:
> On Sat, Sep 17, 2005 at 02:18:28PM +0200, Roman Zippel wrote:
> > Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency,
> > something like this should work:
>
> yes, I agree. Looking at the behaviour of "menuconfig", I think your
> suggestion solves the problem. I didn't try to compile all the
> combinations, though.
>
> I'll submit a patch via DaveM soon.
OK, I'll test it as soon as it appears here :-)
- Arnaldo
^ permalink raw reply
* Re: [HELP] netfilter Kconfig dependency nightmare
From: Harald Welte @ 2005-09-17 15:29 UTC (permalink / raw)
To: Roman Zippel
Cc: Linux Netdev List, Netfilter Development Mailinglist,
Linux Kernel Mailinglist, Arnaldo Carvalho de Melo
In-Reply-To: <Pine.LNX.4.61.0509171407460.3743@scrub.home>
[-- Attachment #1: Type: text/plain, Size: 742 bytes --]
On Sat, Sep 17, 2005 at 02:18:28PM +0200, Roman Zippel wrote:
> Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency,
> something like this should work:
yes, I agree. Looking at the behaviour of "menuconfig", I think your
suggestion solves the problem. I didn't try to compile all the
combinations, though.
I'll submit a patch via DaveM soon.
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Route cache performance
From: jamal @ 2005-09-17 15:17 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050917002823.GB19112@netnation.com>
On Fri, 2005-16-09 at 17:28 -0700, Simon Kirby wrote:
> nf_iterate was near the top even though the firewall was empty, so I
> changed CONFIG_IP_NF_IPTABLES=y to CONFIG_IP_NF_IPTABLES=m (and didn't
> load it). Throughput went up from 173 Mbps to 232 Mbps...yikes.
> Conntrack was never compiled. I'll do some more profiling when I get
> a chance...
>
If you want some basic stateless firewalling, turn off netfilter and use
tc ingress/egress actions instead. The impact on performance is a lot
more tolerable.
cheers,
jamal
^ permalink raw reply
* Re: Ethernet interface problem -- system lockup.
From: Jiri Slaby @ 2005-09-17 13:06 UTC (permalink / raw)
To: simon.d.matthews, Linux Kernel Mailing List, netdev
In-Reply-To: <40b4372005091616024e4dd9a3@mail.gmail.com>
Simon Matthews napsal(a):
>The machine became unresponsive immediately after this. It would not
>respond to either the network, or keyboard.
>
>It is running a RedHat kernel 2.4.20 or similar.
>
>
2.4.31 update?
>Sep 15 16:20:28 xxxx kernel: eth1: Error -- Rx packet size(8172) > mtu(1500)+14
>Sep 15 16:20:28 xxxx kernel: eth1: Error -- Rx packet size(8172) > mtu(1500)+14
>Sep 15 16:20:28 xxxx last message repeated 9 times
>Sep 15 16:20:28 xxxx kernel: eth1: Error -- Rx packet size(4391) > mtu(1500)+14
>Sep 15 16:21:19 xxxx last message repeated 8 times
>Sep 15 16:21:19 xxxx kernel: eth1: Rx ERROR!!!
>Sep 15 16:21:20 xxxx last message repeated 31 times
>Sep 15 16:21:20 xxxx kernel: !!!
>Sep 15 16:21:20 xxxx kernel: !!!
>Sep 15 16:21:20 xxxx kernel: eth1: Rx ERR!!!
>Sep 15 16:21:20 xxxx kernel: eth1: Rx ERR!!!
>Sep 15 16:21:20 xxxx kernel: eth1: Rx ERRO!!!
>Sep 15 16:21:20 xxxx kernel: eth1: Rx ERRO!!!
>Sep 15 16:21:20 xxxx kernel: eth1: Rx ERR!!!
>
>
Is it possible to tell kernel to be more debug (and syslog)?
Which drivers? Which hardware? .config
Some more info needed.
Maybe netdev is beeter mailing list for this.
thanks,
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
^ permalink raw reply
* Re: [HELP] netfilter Kconfig dependency nightmare
From: Roman Zippel @ 2005-09-17 12:18 UTC (permalink / raw)
To: Harald Welte
Cc: Arnaldo Carvalho de Melo, Netfilter Development Mailinglist,
Linux Netdev List, Linux Kernel Mailinglist
In-Reply-To: <20050917112949.GZ8413@sunbeam.de.gnumonks.org>
Hi,
On Sat, 17 Sep 2005, Harald Welte wrote:
> If CONFIG_IP_NF_CONNTRACK_NETLINK is selected (M or Y), then
> CONFIG_IP_NF_CONNTRACK conditionally adds some code that references
> symbols from nfnetlink.ko (CONFIG_NETFILTER_NETLINK)
>
> So basically, enabling CONFIG_IP_NF_CONNTRACK_NETLINK creates a dependency
> from CONFIG_IP_NF_CONNTRACK to CONFIG_NETFILTER_NETLINK. AFAIK, the syntax
> doesn't allow somthing like
>
> tristate IP_NF_CONNTRACK
> depends on NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n
Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency,
something like this should work:
config IP_NF_CONNTRACK_NETLINK
depends on IP_NF_CONNTRACK && NETFILTER_NETLINK
depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m
IOW ct_nl depends on (ct && nl) unless (ct=y && nl=m).
bye, Roman
^ permalink raw reply
* Re: [HELP] netfilter Kconfig dependency nightmare
From: Harald Welte @ 2005-09-17 11:29 UTC (permalink / raw)
To: Roman Zippel
Cc: Linux Netdev List, Netfilter Development Mailinglist,
Linux Kernel Mailinglist, Arnaldo Carvalho de Melo
In-Reply-To: <Pine.LNX.4.61.0509171306290.3743@scrub.home>
[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]
On Sat, Sep 17, 2005 at 01:08:58PM +0200, Roman Zippel wrote:
> Hi,
Hi Roman, thanks for your reply.
> On Sat, 17 Sep 2005, Harald Welte wrote:
>
> > ip_conntrack == CONFIG_IP_NF_CONNTRACK
> > nfnetlink == CONFIG_NETFILTER_NETLINK
> > ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK
> >
> > If nfnetlink == N, ip_conntrack can be N or M or Y
> > If nfnetlink == M, ip_conntrack can be N or M
> > If nfnetlink == Y, ip_conntrack can be Y or M
>
> Where is the requirement for the last one coming from?
sorry. The last one should be N,M or Y.
The fundamental underlying problem is:
If CONFIG_IP_NF_CONNTRACK_NETLINK is selected (M or Y), then
CONFIG_IP_NF_CONNTRACK conditionally adds some code that references
symbols from nfnetlink.ko (CONFIG_NETFILTER_NETLINK)
So basically, enabling CONFIG_IP_NF_CONNTRACK_NETLINK creates a dependency
from CONFIG_IP_NF_CONNTRACK to CONFIG_NETFILTER_NETLINK. AFAIK, the syntax
doesn't allow somthing like
tristate IP_NF_CONNTRACK
depends on NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n
So, if ip_conntrack_netlink == M (or Y), and ip_conntrack == Y, then
nfnetlink has to be set to Y (but cannot be a module).
Is there something that resembles
And no, I do not see any chance to solve the problem in the code,
without either
1) adding yet another new module that only contains some 1kB of code and
that requires additional EXPORT_SYMBOLS() on private data from
ip_conntrack
or
2) adding dead code to ip_conntrack.ko that isn't used in many common
configurations
:(
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [HELP] netfilter Kconfig dependency nightmare
From: Roman Zippel @ 2005-09-17 11:08 UTC (permalink / raw)
To: Harald Welte
Cc: Arnaldo Carvalho de Melo, Netfilter Development Mailinglist,
Linux Netdev List, Linux Kernel Mailinglist
In-Reply-To: <20050917080714.GV8413@sunbeam.de.gnumonks.org>
Hi,
On Sat, 17 Sep 2005, Harald Welte wrote:
> ip_conntrack == CONFIG_IP_NF_CONNTRACK
> nfnetlink == CONFIG_NETFILTER_NETLINK
> ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK
>
> If nfnetlink == N, ip_conntrack can be N or M or Y
> If nfnetlink == M, ip_conntrack can be N or M
> If nfnetlink == Y, ip_conntrack can be Y or M
Where is the requirement for the last one coming from?
> If ip_conntrack == N && nfnetlink == N, ip_conntrack_netlink must be N
> If ip_conntrack == N && nfnetlink == M, ip_conntrack_netlink must be N
> If ip_conntrack == N && nfnetlink == Y, ip_conntrack_netlink must be N
>
> If ip_conntrack == M && nfnetlink == N, ip_conntrack_netlink must be N
> If ip_conntrack == M && nfnetlink == M, ip_conntrack_netlink can N or M
> If ip_conntrack == M && nfnetlink == Y, ip_conntrack_netlink can N or M
>
> if ip_conntrack == Y && nfnetlink == N, ip_conntrack_netlink must be N
> if ip_conntrack == Y && nfnetlink == M, ip_conntrack_netlink can N or M
> if ip_conntrack == Y && nfnetlink == Y, ip_conntrack_netlink can N, M or Y
That looks like a normal ip_conntrack && nfnetlink.
bye, Roman
^ permalink raw reply
* Re: Route cache performance
From: Martin Josefsson @ 2005-09-17 9:04 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050917002823.GB19112@netnation.com>
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
On Fri, 2005-09-16 at 17:28 -0700, Simon Kirby wrote:
> I got stuck in some mud again, but I was able to run a small oprofile.
>
> nf_iterate was near the top even though the firewall was empty, so I
> changed CONFIG_IP_NF_IPTABLES=y to CONFIG_IP_NF_IPTABLES=m (and didn't
> load it). Throughput went up from 173 Mbps to 232 Mbps...yikes.
> Conntrack was never compiled. I'll do some more profiling when I get
> a chance...
Yes, it's bloody slow even without any rules loaded at the moment, it's
on my todo list...
If you want even less overhead then don't even select CONFIG_NETFILTER,
that way you avoid compiling in the netfilter hooks completely.
--
/Martin
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [HELP] netfilter Kconfig dependency nightmare
From: Harald Welte @ 2005-09-17 8:07 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Linux Netdev List, Netfilter Development Mailinglist,
Linux Kernel Mailinglist
In-Reply-To: <20050917012315.GA29841@mandriva.com>
[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]
On Fri, Sep 16, 2005 at 10:23:15PM -0300, Arnaldo Carvalho de Melo wrote:
> After applying this patch I still get a loop:
>
> [acme@toy net-2.6]$ make O=OUTPUT/oops/ oldconfig | grep Warning
> Warning! Found recursive dependency: IP_NF_CONNTRACK_NETLINK NETFILTER_NETLINK IP_NF_CONNTRACK_NETLINK
> Warning! Found recursive dependency: NETFILTER_NETLINK IP_NF_CONNTRACK_NETLINK NETFILTER_NETLINK NETFILTER_NETLINK_QUEUE
>
> This is using latest Dave tree, the one just before master.kernel.org
> was switched off for moving to Oregon, is there any other patch I should
> apply?
This f!*#$%!#$%ing kconfig dependency is killing me. We have this
incredible inter-dependency between various options, and with every new
feature it's getting more complex. The main reason being to avoid some
bits of dead code in case it's not really needed by some other module.
I'm starting to wonder whether it's really worth saving those few bytes
in some configurations at the expense of this complexity.
Maybe some Kconfig freak can help out. This is the intended dependency
rules:
ip_conntrack == CONFIG_IP_NF_CONNTRACK
nfnetlink == CONFIG_NETFILTER_NETLINK
ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK
If nfnetlink == N, ip_conntrack can be N or M or Y
If nfnetlink == M, ip_conntrack can be N or M
If nfnetlink == Y, ip_conntrack can be Y or M
If ip_conntrack == N && nfnetlink == N, ip_conntrack_netlink must be N
If ip_conntrack == N && nfnetlink == M, ip_conntrack_netlink must be N
If ip_conntrack == N && nfnetlink == Y, ip_conntrack_netlink must be N
If ip_conntrack == M && nfnetlink == N, ip_conntrack_netlink must be N
If ip_conntrack == M && nfnetlink == M, ip_conntrack_netlink can N or M
If ip_conntrack == M && nfnetlink == Y, ip_conntrack_netlink can N or M
if ip_conntrack == Y && nfnetlink == N, ip_conntrack_netlink must be N
if ip_conntrack == Y && nfnetlink == M, ip_conntrack_netlink can N or M
if ip_conntrack == Y && nfnetlink == Y, ip_conntrack_netlink can N, M or Y
NETfILTER_NETLINK_QUEUE and NETFILTER_NETLINK_LOG only depend on
NETFILER_NETLINK and nothing else.
Cheers,
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-09-17 0:28 UTC (permalink / raw)
To: Robert Olsson; +Cc: Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <17191.55685.861191.831981@robur.slu.se>
On Wed, Sep 14, 2005 at 10:04:21AM +0200, Robert Olsson wrote:
>
> Simon Kirby writes:
>
>
> > Sender: 367 Mbps, 717883 pps valid src/dst, 64 byte (Ethernet) packets
> >
> > 2.4.27-rc1: 297 Mbps forwarded (w/idle time?!)
> > 2.4.31: 296 Mbps forwarded (w/idle time?!)
> > 2.6.13-rc6: 173 Mbps forwarded
>
> > Time permitting, I'd also like to run some profiles. It's interesting
> > to note that 2.6 is slower at forwarding even straight duplicate small
> > packets. We should definitely get to the bottom of that.
>
> Yes. This is single flow? Strange.
>
> Run a fixed size shot 10Mpkts pkts or so for both 2.4 and 2.6 and save
> /proc/interrupts, proc/net/softnetstat, netstat -i, tc -s qdisc to start with.
I got stuck in some mud again, but I was able to run a small oprofile.
nf_iterate was near the top even though the firewall was empty, so I
changed CONFIG_IP_NF_IPTABLES=y to CONFIG_IP_NF_IPTABLES=m (and didn't
load it). Throughput went up from 173 Mbps to 232 Mbps...yikes.
Conntrack was never compiled. I'll do some more profiling when I get
a chance...
Simon-
^ permalink raw reply
* 遅くなりました。
From: 水野直美 @ 2005-09-16 21:39 UTC (permalink / raw)
To: netdev
遅くなっちゃいましたが、
なんとか、金曜日休み取れました。
http://specialterm.com
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Al Boldi @ 2005-09-16 21:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, netdev
In-Reply-To: <20050916073818.GA15990@havoc.gtf.org>
Jeff Garzik wrote:
> Please pull from 'upstream-fixes' branch of
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
Does it fix the tulip mii-link detection problem on wire-disconnect?
--
Al
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-09-16 19:57 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Robert Olsson, Simon Kirby, Eric Dumazet, netdev
In-Reply-To: <20050916190404.GA11012@yakov.inr.ac.ru>
Alexey Kuznetsov writes:
> Most likely, something is broken in the e1000 driver. Otherwise, no ideas.
No it's hard to guess. Simon will hopefully bring some more data.
> I do not see _why_. Apparently some overhead is present but I do not
> understand why it is so large. Is it just because 300 redundant entries
> pollute cache a little more? I do not see another reasons.
Yes when RX softirq is done. RCU tasklet has to take over and probably
reload cache with some the entries to complete the deletion. It might be
worth a profile...
> Maybe it makes sense to compare this effect with the effect of increment
> gc_elasticity by 1. If it is due to cache pollution, effect of increment
> of gc_elasticity, which increses size of cache by rhash_size should be
> even worse.
Something like that yes :) but if we increase gc_elasticity we also add
more spinning in hash chains. So we need to sort out if the expected
performance drop comes from extra hash spinning or are cache effects from
the increased hash.
Cheers.
--ro
^ permalink raw reply
* Re: Route cache performance
From: Ben Greear @ 2005-09-16 19:22 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Robert Olsson, Simon Kirby, Eric Dumazet, netdev
In-Reply-To: <20050916190404.GA11012@yakov.inr.ac.ru>
Alexey Kuznetsov wrote:
> Hello!
>
>
>>Yes sounds famliar XEON with e1000... So why not for 2.6?
>
>
> Most likely, something is broken in the e1000 driver. Otherwise, no ideas.
Has anyone tried using bridging to compare numbers? I would assume that
the bridging code is lower-overhead than the routing, so if it's a route
cache problem, the bridge traffic should be significantly higher than
the routed traffic. If they are both about the same, then either
bridging has lots of overhead too, or the driver (or other network
sub-system) is the bottleneck.
For reference, I was able to bridge only about 200kpps (in each direction, 64 byte pkts)
on a P-IV 3Ghz system with dual Intel e1000 NIC in a PCI-X 64/133 bus....
I would like to hear of any other bridging benchmarks that someone
may have, especially for bi-directional traffic flows.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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