* Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Francois Romieu @ 2005-10-25 21:59 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Stephen Hemminger, Jeff Garzik, Manfred Spraul, Netdev
In-Reply-To: <DBFABB80F7FD3143A911F9E6CFD477B00BA5D790@hqemmail02.nvidia.com>
Ayaz Abdulla <AAbdulla@nvidia.com> :
> We give the fragments in that order to ensure they are all setup before
> hardware starts looking at them.
If you are curious of different ways to do it, you can look at:
- drivers/net/r8169.c::rtl8169_start_xmit
- drivers/net/skge.c::skge_xmit_frame
drivers/net/bnx2.c::bnx2_start_xmit seems bogus.
--
Ueimor
^ permalink raw reply
* [PATCH] 5/5 ibmveth fix failed addbuf
From: Santiago Leon @ 2005-10-25 21:39 UTC (permalink / raw)
To: netdev, lkml; +Cc: Jeff Garzik
This patch fixes a bug that happens when the hypervisor can't add a
buffer. The old code wrote IBM_VETH_INVALID_MAP into the free_map
array, so next time the index was used, a ibmveth_assert() caught it and
called BUG(). The patch writes the right value into the free_map array
so that the index can be reused.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
---
drivers/net/ibmveth.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
---
diff -urN a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2005-10-17 12:35:13.000000000 -0500
+++ b/drivers/net/ibmveth.c 2005-10-17 12:36:13.000000000 -0500
@@ -237,7 +237,7 @@
lpar_rc = h_add_logical_lan_buffer(adapter->vdev->unit_address,
desc.desc);
if(lpar_rc != H_Success) {
- pool->free_map[free_index] = IBM_VETH_INVALID_MAP;
+ pool->free_map[free_index] = index;
pool->skbuff[index] = NULL;
pool->consumer_index--;
dma_unmap_single(&adapter->vdev->dev,
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] 4/5 ibmveth lockless TX
From: Santiago Leon @ 2005-10-25 21:34 UTC (permalink / raw)
To: netdev, lkml; +Cc: Jeff Garzik
This patch adds the lockless TX feature to the ibmveth driver. The
hypervisor has its own locking so the only change that is necessary is
to protect the statistics counters.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
---
drivers/net/ibmveth.c | 44
+++++++++++++++++++++++++++++---------------
drivers/net/ibmveth.h | 1 +
2 files changed, 30 insertions(+), 15 deletions(-)
---
diff -urN a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2005-10-17 12:37:06.000000000 -0500
+++ b/drivers/net/ibmveth.c 2005-10-18 11:58:56.000000000 -0500
@@ -621,12 +621,18 @@
unsigned long lpar_rc;
int nfrags = 0, curfrag;
unsigned long correlator;
+ unsigned long flags;
unsigned int retry_count;
+ unsigned int tx_dropped = 0;
+ unsigned int tx_bytes = 0;
+ unsigned int tx_packets = 0;
+ unsigned int tx_send_failed = 0;
+ unsigned int tx_map_failed = 0;
+
if ((skb_shinfo(skb)->nr_frags + 1) > IbmVethMaxSendFrags) {
- adapter->stats.tx_dropped++;
- dev_kfree_skb(skb);
- return 0;
+ tx_dropped++;
+ goto out;
}
memset(&desc, 0, sizeof(desc));
@@ -645,10 +651,9 @@
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk("tx: unable to map initial fragment\n");
- adapter->tx_map_failed++;
- adapter->stats.tx_dropped++;
- dev_kfree_skb(skb);
- return 0;
+ tx_map_failed++;
+ tx_dropped++;
+ goto out;
}
curfrag = nfrags;
@@ -665,8 +670,8 @@
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag);
- adapter->tx_map_failed++;
- adapter->stats.tx_dropped++;
+ tx_map_failed++;
+ tx_dropped++;
/* Free all the mappings we just created */
while(curfrag < nfrags) {
dma_unmap_single(&adapter->vdev->dev,
@@ -675,8 +680,7 @@
DMA_TO_DEVICE);
curfrag++;
}
- dev_kfree_skb(skb);
- return 0;
+ goto out;
}
}
@@ -701,11 +705,11 @@
ibmveth_error_printk("tx: desc[%i] valid=%d, len=%d, address=0x%d\n", i,
desc[i].fields.valid, desc[i].fields.length,
desc[i].fields.address);
}
- adapter->tx_send_failed++;
- adapter->stats.tx_dropped++;
+ tx_send_failed++;
+ tx_dropped++;
} else {
- adapter->stats.tx_packets++;
- adapter->stats.tx_bytes += skb->len;
+ tx_packets++;
+ tx_bytes += skb->len;
netdev->trans_start = jiffies;
}
@@ -715,6 +719,14 @@
desc[nfrags].fields.length, DMA_TO_DEVICE);
} while(--nfrags >= 0);
+out: spin_lock_irqsave(&adapter->stats_lock, flags);
+ adapter->stats.tx_dropped += tx_dropped;
+ adapter->stats.tx_bytes += tx_bytes;
+ adapter->stats.tx_packets += tx_packets;
+ adapter->tx_send_failed += tx_send_failed;
+ adapter->tx_map_failed += tx_map_failed;
+ spin_unlock_irqrestore(&adapter->stats_lock, flags);
+
dev_kfree_skb(skb);
return 0;
}
@@ -980,6 +992,8 @@
netdev->ethtool_ops = &netdev_ethtool_ops;
netdev->change_mtu = ibmveth_change_mtu;
SET_NETDEV_DEV(netdev, &dev->dev);
+ netdev->features |= NETIF_F_LLTX;
+ spin_lock_init(&adapter->stats_lock);
memcpy(&netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
diff -urN a/drivers/net/ibmveth.h b/drivers/net/ibmveth.h
--- a/drivers/net/ibmveth.h 2005-10-17 12:35:13.000000000 -0500
+++ b/drivers/net/ibmveth.h 2005-10-18 11:58:56.000000000 -0500
@@ -131,6 +131,7 @@
u64 tx_linearize_failed;
u64 tx_map_failed;
u64 tx_send_failed;
+ spinlock_t stats_lock;
};
struct ibmveth_buf_desc_fields {
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] 3/5 ibmveth fix buffer replenishing
From: Santiago Leon @ 2005-10-25 21:34 UTC (permalink / raw)
To: netdev, lkml; +Cc: Jeff Garzik
This patch removes the allocation of RX skb's buffers from a workqueue
to be called directly at RX processing time. This change was suggested
by Dave Miller when the driver was starving the RX buffers and
deadlocking under heavy traffic:
> Allocating RX SKBs via tasklet is, IMHO, the worst way to
> do it. It is no surprise that there are starvation cases.
>
> If tasklets or work queues get delayed in any way, you lose,
> and it's very easy for a card to catch up with the driver RX'ing
> packets very fast, no matter how aggressive you make the
> replenishing. By the time you detect that you need to be
> "more aggressive" it is already too late.
> The only pseudo-reliable way is to allocate at RX processing time.
>
Signed-off-by: Santiago Leon <santil@us.ibm.com>
---
drivers/net/ibmveth.c | 48
++++++++----------------------------------------
drivers/net/ibmveth.h | 4 ----
2 files changed, 8 insertions(+), 44 deletions(-)
---
diff -urN a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2005-10-17 12:04:58.000000000 -0500
+++ b/drivers/net/ibmveth.c 2005-10-17 12:23:22.000000000 -0500
@@ -96,7 +96,6 @@
static void ibmveth_proc_register_adapter(struct ibmveth_adapter
*adapter);
static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter
*adapter);
static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance, struct
pt_regs *regs);
-static inline void ibmveth_schedule_replenishing(struct
ibmveth_adapter*);
static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter
*adapter);
#ifdef CONFIG_PROC_FS
@@ -257,29 +256,7 @@
atomic_add(buffers_added, &(pool->available));
}
-/* check if replenishing is needed. */
-static inline int ibmveth_is_replenishing_needed(struct ibmveth_adapter
*adapter)
-{
- int i;
-
- for(i = 0; i < IbmVethNumBufferPools; i++)
- if(adapter->rx_buff_pool[i].active &&
- (atomic_read(&adapter->rx_buff_pool[i].available) <
- adapter->rx_buff_pool[i].threshold))
- return 1;
- return 0;
-}
-
-/* kick the replenish tasklet if we need replenishing and it isn't
already running */
-static inline void ibmveth_schedule_replenishing(struct ibmveth_adapter
*adapter)
-{
- if(ibmveth_is_replenishing_needed(adapter) &&
- (atomic_dec_if_positive(&adapter->not_replenishing) == 0)) {
- schedule_work(&adapter->replenish_task);
- }
-}
-
-/* replenish tasklet routine */
+/* replenish routine */
static void ibmveth_replenish_task(struct ibmveth_adapter *adapter)
{
int i;
@@ -292,10 +269,6 @@
&adapter->rx_buff_pool[i]);
adapter->rx_no_buffer = *(u64*)(((char*)adapter->buffer_list_addr) +
4096 - 8);
-
- atomic_inc(&adapter->not_replenishing);
-
- ibmveth_schedule_replenishing(adapter);
}
/* empty and free ana buffer pool - also used to do cleanup in error
paths */
@@ -563,10 +536,10 @@
return rc;
}
- netif_start_queue(netdev);
+ ibmveth_debug_printk("initial replenish cycle\n");
+ ibmveth_replenish_task(adapter);
- ibmveth_debug_printk("scheduling initial replenish cycle\n");
- ibmveth_schedule_replenishing(adapter);
+ netif_start_queue(netdev);
ibmveth_debug_printk("open complete\n");
@@ -584,9 +557,6 @@
free_irq(netdev->irq, netdev);
- cancel_delayed_work(&adapter->replenish_task);
- flush_scheduled_work();
-
do {
lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
} while (H_isLongBusy(lpar_rc) || (lpar_rc == H_Busy));
@@ -795,7 +765,7 @@
}
} while(more_work && (frames_processed < max_frames_to_process));
- ibmveth_schedule_replenishing(adapter);
+ ibmveth_replenish_task(adapter);
if(more_work) {
/* more work to do - return that we are not done yet */
@@ -931,8 +901,10 @@
}
+ /* kick the interrupt handler so that the new buffer pools get
+ replenished or deallocated */
+ ibmveth_interrupt(dev->irq, dev, NULL);
- ibmveth_schedule_replenishing(adapter);
dev->mtu = new_mtu;
return 0;
}
@@ -1017,14 +989,10 @@
ibmveth_debug_printk("adapter @ 0x%p\n", adapter);
- INIT_WORK(&adapter->replenish_task, (void*)ibmveth_replenish_task,
(void*)adapter);
-
adapter->buffer_list_dma = DMA_ERROR_CODE;
adapter->filter_list_dma = DMA_ERROR_CODE;
adapter->rx_queue.queue_dma = DMA_ERROR_CODE;
- atomic_set(&adapter->not_replenishing, 1);
-
ibmveth_debug_printk("registering netdev...\n");
rc = register_netdev(netdev);
diff -urN a/drivers/net/ibmveth.h b/drivers/net/ibmveth.h
--- a/drivers/net/ibmveth.h 2005-10-17 12:04:58.000000000 -0500
+++ b/drivers/net/ibmveth.h 2005-10-17 12:23:22.000000000 -0500
@@ -118,10 +118,6 @@
dma_addr_t filter_list_dma;
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
- atomic_t not_replenishing;
-
- /* helper tasks */
- struct work_struct replenish_task;
/* adapter specific stats */
u64 replenish_task_cycles;
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] 2/5 ibmveth fix buffer pool management
From: Santiago Leon @ 2005-10-25 21:34 UTC (permalink / raw)
To: netdev, lkml; +Cc: Jeff Garzik
This patch changes the way the ibmveth driver handles the receive
buffers. The old code mallocs and maps all the buffers in the pools
regardless of MTU size and it also limits the number of buffer pools to
three. This patch makes the driver malloc and map the buffers necessary
to support the current MTU. It also changes the hardcoded names of the
buffer pool number, size, and elements to arrays to make it easier to
change (with the hope of making them runtime parameters in the future).
Signed-off-by: Santiago Leon <santil@us.ibm.com>
---
drivers/net/ibmveth.c | 102
++++++++++++++++++++++++++++++++++++--------------
drivers/net/ibmveth.h | 18 +++++---
2 files changed, 85 insertions(+), 35 deletions(-)
---
diff -urN a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2005-10-17 11:59:57.000000000 -0500
+++ b/drivers/net/ibmveth.c 2005-10-17 12:02:03.000000000 -0500
@@ -97,6 +97,7 @@
static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter
*adapter);
static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance, struct
pt_regs *regs);
static inline void ibmveth_schedule_replenishing(struct
ibmveth_adapter*);
+static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter
*adapter);
#ifdef CONFIG_PROC_FS
#define IBMVETH_PROC_DIR "net/ibmveth"
@@ -181,6 +182,7 @@
atomic_set(&pool->available, 0);
pool->producer_index = 0;
pool->consumer_index = 0;
+ pool->active = 0;
return 0;
}
@@ -258,9 +260,14 @@
/* check if replenishing is needed. */
static inline int ibmveth_is_replenishing_needed(struct ibmveth_adapter
*adapter)
{
- return ((atomic_read(&adapter->rx_buff_pool[0].available) <
adapter->rx_buff_pool[0].threshold) ||
- (atomic_read(&adapter->rx_buff_pool[1].available) <
adapter->rx_buff_pool[1].threshold) ||
- (atomic_read(&adapter->rx_buff_pool[2].available) <
adapter->rx_buff_pool[2].threshold));
+ int i;
+
+ for(i = 0; i < IbmVethNumBufferPools; i++)
+ if(adapter->rx_buff_pool[i].active &&
+ (atomic_read(&adapter->rx_buff_pool[i].available) <
+ adapter->rx_buff_pool[i].threshold))
+ return 1;
+ return 0;
}
/* kick the replenish tasklet if we need replenishing and it isn't
already running */
@@ -275,11 +282,14 @@
/* replenish tasklet routine */
static void ibmveth_replenish_task(struct ibmveth_adapter *adapter)
{
+ int i;
+
adapter->replenish_task_cycles++;
- ibmveth_replenish_buffer_pool(adapter, &adapter->rx_buff_pool[0]);
- ibmveth_replenish_buffer_pool(adapter, &adapter->rx_buff_pool[1]);
- ibmveth_replenish_buffer_pool(adapter, &adapter->rx_buff_pool[2]);
+ for(i = 0; i < IbmVethNumBufferPools; i++)
+ if(adapter->rx_buff_pool[i].active)
+ ibmveth_replenish_buffer_pool(adapter,
+ &adapter->rx_buff_pool[i]);
adapter->rx_no_buffer = *(u64*)(((char*)adapter->buffer_list_addr) +
4096 - 8);
@@ -321,6 +331,7 @@
kfree(pool->skbuff);
pool->skbuff = NULL;
}
+ pool->active = 0;
}
/* remove a buffer from a pool */
@@ -379,6 +390,12 @@
ibmveth_assert(pool < IbmVethNumBufferPools);
ibmveth_assert(index < adapter->rx_buff_pool[pool].size);
+ if(!adapter->rx_buff_pool[pool].active) {
+ ibmveth_rxq_harvest_buffer(adapter);
+ ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[pool]);
+ return;
+ }
+
desc.desc = 0;
desc.fields.valid = 1;
desc.fields.length = adapter->rx_buff_pool[pool].buff_size;
@@ -409,6 +426,8 @@
static void ibmveth_cleanup(struct ibmveth_adapter *adapter)
{
+ int i;
+
if(adapter->buffer_list_addr != NULL) {
if(!dma_mapping_error(adapter->buffer_list_dma)) {
dma_unmap_single(&adapter->vdev->dev,
@@ -443,26 +462,24 @@
adapter->rx_queue.queue_addr = NULL;
}
- ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[0]);
- ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[1]);
- ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[2]);
+ for(i = 0; i<IbmVethNumBufferPools; i++)
+ ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[i]);
}
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev->priv;
u64 mac_address = 0;
- int rxq_entries;
+ int rxq_entries = 1;
unsigned long lpar_rc;
int rc;
union ibmveth_buf_desc rxq_desc;
+ int i;
ibmveth_debug_printk("open starting\n");
- rxq_entries =
- adapter->rx_buff_pool[0].size +
- adapter->rx_buff_pool[1].size +
- adapter->rx_buff_pool[2].size + 1;
+ for(i = 0; i<IbmVethNumBufferPools; i++)
+ rxq_entries += adapter->rx_buff_pool[i].size;
adapter->buffer_list_addr = (void*) get_zeroed_page(GFP_KERNEL);
adapter->filter_list_addr = (void*) get_zeroed_page(GFP_KERNEL);
@@ -502,14 +519,8 @@
adapter->rx_queue.num_slots = rxq_entries;
adapter->rx_queue.toggle = 1;
- if(ibmveth_alloc_buffer_pool(&adapter->rx_buff_pool[0]) ||
- ibmveth_alloc_buffer_pool(&adapter->rx_buff_pool[1]) ||
- ibmveth_alloc_buffer_pool(&adapter->rx_buff_pool[2]))
- {
- ibmveth_error_printk("unable to allocate buffer pools\n");
- ibmveth_cleanup(adapter);
- return -ENOMEM;
- }
+ /* call change_mtu to init the buffer pools based in initial mtu */
+ ibmveth_change_mtu(netdev, netdev->mtu);
memcpy(&mac_address, netdev->dev_addr, netdev->addr_len);
mac_address = mac_address >> 16;
@@ -885,17 +896,52 @@
static int ibmveth_change_mtu(struct net_device *dev, int new_mtu)
{
- if ((new_mtu < 68) || (new_mtu > (1<<20)))
+ struct ibmveth_adapter *adapter = dev->priv;
+ int i;
+ int prev_smaller = 1;
+
+ if ((new_mtu < 68) ||
+ (new_mtu > (pool_size[IbmVethNumBufferPools-1]) -
IBMVETH_BUFF_OH))
return -EINVAL;
+
+ for(i = 0; i<IbmVethNumBufferPools; i++) {
+ int activate = 0;
+ if (new_mtu > (pool_size[i] - IBMVETH_BUFF_OH)) {
+ activate = 1;
+ prev_smaller= 1;
+ } else {
+ if (prev_smaller)
+ activate = 1;
+ prev_smaller= 0;
+ }
+
+ if (activate && !adapter->rx_buff_pool[i].active) {
+ struct ibmveth_buff_pool *pool =
+ &adapter->rx_buff_pool[i];
+ if(ibmveth_alloc_buffer_pool(pool)) {
+ ibmveth_error_printk("unable to alloc pool\n");
+ return -ENOMEM;
+ }
+ adapter->rx_buff_pool[i].active = 1;
+ } else if (!activate && adapter->rx_buff_pool[i].active) {
+ adapter->rx_buff_pool[i].active = 0;
+ h_free_logical_lan_buffer(adapter->vdev->unit_address,
+ (u64)pool_size[i]);
+ }
+
+ }
+
+
+ ibmveth_schedule_replenishing(adapter);
dev->mtu = new_mtu;
return 0;
}
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct
vio_device_id *id)
{
- int rc;
+ int rc, i;
struct net_device *netdev;
- struct ibmveth_adapter *adapter;
+ struct ibmveth_adapter *adapter = NULL;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -965,9 +1011,9 @@
memcpy(&netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
- ibmveth_init_buffer_pool(&adapter->rx_buff_pool[0], 0,
IbmVethPool0DftCnt, IbmVethPool0DftSize);
- ibmveth_init_buffer_pool(&adapter->rx_buff_pool[1], 1,
IbmVethPool1DftCnt, IbmVethPool1DftSize);
- ibmveth_init_buffer_pool(&adapter->rx_buff_pool[2], 2,
IbmVethPool2DftCnt, IbmVethPool2DftSize);
+ for(i = 0; i<IbmVethNumBufferPools; i++)
+ ibmveth_init_buffer_pool(&adapter->rx_buff_pool[i], i,
+ pool_count[i], pool_size[i]);
ibmveth_debug_printk("adapter @ 0x%p\n", adapter);
diff -urN a/drivers/net/ibmveth.h b/drivers/net/ibmveth.h
--- a/drivers/net/ibmveth.h 2005-06-17 14:48:29.000000000 -0500
+++ b/drivers/net/ibmveth.h 2005-10-17 12:00:25.000000000 -0500
@@ -49,6 +49,7 @@
#define H_SEND_LOGICAL_LAN 0x120
#define H_MULTICAST_CTRL 0x130
#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
@@ -69,13 +70,15 @@
#define h_change_logical_lan_mac(ua, mac) \
plpar_hcall_norets(H_CHANGE_LOGICAL_LAN_MAC, ua, mac)
-#define IbmVethNumBufferPools 3
-#define IbmVethPool0DftSize (1024 * 2)
-#define IbmVethPool1DftSize (1024 * 4)
-#define IbmVethPool2DftSize (1024 * 10)
-#define IbmVethPool0DftCnt 256
-#define IbmVethPool1DftCnt 256
-#define IbmVethPool2DftCnt 256
+#define h_free_logical_lan_buffer(ua, bufsize) \
+ plpar_hcall_norets(H_FREE_LOGICAL_LAN_BUFFER, ua, bufsize)
+
+#define IbmVethNumBufferPools 5
+#define IBMVETH_BUFF_OH 22 /* Overhead: 14 ethernet header + 8 opaque
handle */
+
+/* pool_size should be sorted */
+static int pool_size[] = { 512, 1024 * 2, 1024 * 16, 1024 * 32, 1024 *
64 };
+static int pool_count[] = { 256, 768, 256, 256, 256 };
#define IBM_VETH_INVALID_MAP ((u16)0xffff)
@@ -90,6 +93,7 @@
u16 *free_map;
dma_addr_t *dma_addr;
struct sk_buff **skbuff;
+ int active;
};
struct ibmveth_rx_q {
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH] 1/5 ibmveth fix bonding
From: Santiago Leon @ 2005-10-25 21:27 UTC (permalink / raw)
To: netdev, lkml; +Cc: Jeff Garzik
This patch updates dev->trans_start and dev->last_rx so that the ibmveth
driver can be used with the ARP monitor in the bonding driver.
Signed-off-by: Santiago Leon <santil@us.ibm.com>
---
drivers/net/ibmveth.c | 2 ++
1 files changed, 2 insertions(+)
---
diff -urN a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
--- a/drivers/net/ibmveth.c 2005-10-11 12:56:24.000000000 -0500
+++ b/drivers/net/ibmveth.c 2005-10-11 13:52:45.000000000 -0500
@@ -725,6 +725,7 @@
} else {
adapter->stats.tx_packets++;
adapter->stats.tx_bytes += skb->len;
+ netdev->trans_start = jiffies;
}
do {
@@ -776,6 +777,7 @@
adapter->stats.rx_packets++;
adapter->stats.rx_bytes += length;
frames_processed++;
+ netdev->last_rx = jiffies;
}
} else {
more_work = 0;
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* RE: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Ayaz Abdulla @ 2005-10-25 21:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, Manfred Spraul, Netdev
We give the fragments in that order to ensure they are all setup before
hardware starts looking at them.
I can fix up the coding style issue in another patch. That has been
there since day 1 and is not related to this patch.
-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]
Sent: Monday, October 24, 2005 2:21 PM
To: Ayaz Abdulla
Cc: Jeff Garzik; Manfred Spraul; Netdev
Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation
offload support
On Mon, 24 Oct 2005 12:48:07 -0400
Ayaz Abdulla <aabdulla@nvidia.com> wrote:
> Jeff,
>
> I made the changes you requested. Here is the new patch.
>
> Thanks,
> Ayaz
>
> Signed-off-By: Ayaz Abdulla <aabdulla@nvidia.com>
>
There are really three patches in here.
1. Use netdev_priv (trivial)
2. scatter/gather support
3. TSO support
Why do you set the fragments up in reverse order? Going backwards is
usually slow on most code.
The kernel coding style is to use lower case in local variable names
(Flags)
and structure elements (PacketBuffer, FlagLen).
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: 2.6.14-rc5 e1000 and page allocation failures.. still
From: Bill Davidsen @ 2005-10-25 20:40 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <4807377b0510241528m6afc3501w9d98d66658a38973@mail.gmail.com>
Jesse Brandeburg wrote:
> On 10/23/05, Robert Hancock <hancockr@shaw.ca> wrote:
>
>>John Bäckstrand wrote:
>>
>>>Im seeing a massive amount of page allocation failures with 2.6.14-rc5,
>>>and also earlier kernels, see "E1000 - page allocation failure - saga
>
> [snip]
>
>>It looks like you have enough memory free - the problem is that the
>>driver is allocating a block of memory with order 3, which is 8 pages.
>>Quite likely there are not enough contiguous free pages to satisfy that.
>>
>>That's an awful big buffer size for a packet - I assume you're using
>>jumbo frames or something? Ideally the driver and hardware should be
>>able to allocate a buffer for those packets in multiple chunks, but I
>>have no idea if this is possible.
>
>
> the latest e1000 driver (6.2.15) from http://sf.net/projects/e1000
> fixes this by using multiple descriptors for jumbo frames, therefore
> only doing order 0 (single page) page allocations.
>
> let us know how it goes.
>
> BTW why is this so much more common with recent kernels?
I don't know why it's more common, but I agree that it seems so. I have
speculated that it may be related to 4k stack, but I can't even generate
a credible wild-ass guess on that, much less find any evidence, so I
doubt that's much if any correlation.
Getting memory a page at a time is ugly, but it will probably work just
fine.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Michael Chan @ 2005-10-25 20:30 UTC (permalink / raw)
To: Francois Romieu
Cc: Ayaz Abdulla, Stephen Hemminger, Jeff Garzik, Manfred Spraul,
Netdev
In-Reply-To: <20051025215932.GA17794@electric-eye.fr.zoreil.com>
On Tue, 2005-10-25 at 23:59 +0200, Francois Romieu wrote:
>
> drivers/net/bnx2.c::bnx2_start_xmit seems bogus.
>
Please explain what did you mean by bogus?
^ permalink raw reply
* Re: [patch 2.6.13 0/5] normalize calculations of rx_dropped
From: Ingo Oeser @ 2005-10-25 19:50 UTC (permalink / raw)
To: linux-kernel; +Cc: Ben Greear, John W. Linville, netdev, Jeff Garzik
In-Reply-To: <435D8717.9000107@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
On Tuesday 25 October 2005 03:15, Ben Greear wrote:
> rx_errors: Total of all rx errors
If it is a total, then we don't need to store it, since we can calculate
that explicity on request, no?
> rx_dropped: Dropped on receive, usually due to kernel being over-worked.
> rx_length: Dropped because pkt-length was invalid.
> rx_over: Dropped because we over-ran the NIC's rx buffers.
> rx_crc: Packets received with bad CRC errors.
> rx_frame: Framing errors (errors at the physical layer), usually cable or hardware error.
> rx_fifo: Dropped due to Kernel buffers being full (I guess rx-over could be NIC only, rx-fifo be kernel/driver only.)
> rx_missed: Dropped due to not handling IRQ in time.
Regards
Ingo Oeser
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH/RFC] Remove spurious sk_filter() call from IPv6
From: James Morris @ 2005-10-25 16:48 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
It seems that the IPv6 input path has an extra call to sk_filter().
First, the correct call to sk_filter() in tcp_v6_rcv(), matching the IPv4
code.
Then, again in tcp_v6_do_rcv(), which often results in a somewhat already
processed skb being passed to sk_filter().
As far as I can tell, we should remove this second call, as it is both
incorrect and uncecessary.
Please review and apply if ok.
Signed-off-by: James Morris <jmorris@namei.org>
---
net/ipv6/tcp_ipv6.c | 3 ---
1 files changed, 3 deletions(-)
diff -purN -X dontdiff linux-2.6.14-rc5.o/net/ipv6/tcp_ipv6.c linux-2.6.14-rc5.ipv6/net/ipv6/tcp_ipv6.c
--- linux-2.6.14-rc5.o/net/ipv6/tcp_ipv6.c 2005-10-21 00:43:33.000000000 -0400
+++ linux-2.6.14-rc5.ipv6/net/ipv6/tcp_ipv6.c 2005-10-25 12:44:23.000000000 -0400
@@ -1451,9 +1451,6 @@ static int tcp_v6_do_rcv(struct sock *sk
if (skb->protocol == htons(ETH_P_IP))
return tcp_v4_do_rcv(sk, skb);
- if (sk_filter(sk, skb, 0))
- goto discard;
-
/*
* socket locking is here for SMP purposes as backlog rcv
* is currently called with bh processing disabled.
^ permalink raw reply
* Re: [PATCH]IPv6: fix refcnt of struct ip6_flowlabel
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-10-25 8:22 UTC (permalink / raw)
To: acme; +Cc: yanzheng, netdev, linux-kernel, yoshfuji
In-Reply-To: <39e6f6c70510241135p18b018bo896b3565fa5ce87b@mail.gmail.com>
In article <39e6f6c70510241135p18b018bo896b3565fa5ce87b@mail.gmail.com> (at Mon, 24 Oct 2005 16:35:33 -0200), Arnaldo Carvalho de Melo <acme@ghostprotocols.net> says:
> On 10/24/05, Yan Zheng <yanzheng@21cn.com> wrote:
> > Signed-off-by: Yan Zheng <yanzheng@21cn.com>
> >
> >
> > Index: net/ipv6/ip6_flowlabel.c
> > ===================================================================
> > --- linux-2.6.14-rc5/net/ipv6/ip6_flowlabel.c 2005-10-22 10:31:13.000000000 +0800
> > +++ linux/net/ipv6/ip6_flowlabel.c 2005-10-24 19:55:23.000000000 +0800
> > @@ -483,7 +483,7 @@
> > goto done;
> > }
> > fl1 = sfl->fl;
> > - atomic_inc(&fl->users);
> > + atomic_inc(&fl1->users);
> > break;
>
> Looks OK to me, Yoshifuji-san, ACK?
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
--yoshfuji
^ permalink raw reply
* ethtool git repo created
From: Jeff Garzik @ 2005-10-25 6:38 UTC (permalink / raw)
To: Netdev List; +Cc: Linux Kernel
After sitting around in a non-public subversion repo for far too long,
I've stuffed the latest ethtool source code into a git repository. As
soon as it finished mirroring, it will be available at
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/ethtool.git
^ permalink raw reply
* Re: [PATCH] Ethtool support for the new PowerPC 4xx on-chip ethernet controller driver
From: Jeff Garzik @ 2005-10-25 6:29 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20050831062416.GD17017@gate.ebshome.net>
applied
^ permalink raw reply
* Re: [patch 2.6.13 0/5] normalize calculations of rx_dropped
From: jamal @ 2005-10-25 1:42 UTC (permalink / raw)
To: Ben Greear; +Cc: John W. Linville, linux-kernel, netdev, Jeff Garzik
In-Reply-To: <435D8717.9000107@candelatech.com>
On Mon, 2005-24-10 at 18:15 -0700, Ben Greear wrote:
[..]
> That way, the rx-errors counter can be used for folks who just care
> that the packet was not correctly received, and those that care about
> the details can look at the individual errors (and sum them up in various
> configurations due to personal taste, etc.)
>
Look at http://www.faqs.org/rfcs/rfc2665.html
for a more finer breakdown.
rx/tx_errors may be further broken down.
cheers,
jamal
^ permalink raw reply
* Re: [patch 2.6.13 0/5] normalize calculations of rx_dropped
From: Ben Greear @ 2005-10-25 1:15 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, Jeff Garzik
In-Reply-To: <20051024215751.GH28212@tuxdriver.com>
John W. Linville wrote:
> On Mon, Oct 24, 2005 at 02:35:42PM -0700, Ben Greear wrote:
>
>
>>It doesn't matter too much to me either way, but I'd like for there to
>>be a precisely documented definition for the various net-stats so that
>>I can correctly show the values to user-space (I can certainly add
>>rx_discards
>>to rx_errors for a 'total rx errors' value, but I need to know whether
>>rx_discards is already in rx_errors to keep from counting things twice.)
>
>
> My opinion is that:
>
> -- rx_errors should count all "on the wire" hardware errors;
>
> -- rx_missed_errors should count frames w/ no "on the wire"
> errors that cannot be received by the hardware (generally
> due to lack of DMA bufers); and,
>
> -- rx_discards should count frames dropped by the kernel
> after successful reception by the hardware.
>
> I do _not_ think rx_missed_errors should be counted as part of
> rx_errors, but I could be persuaded otherwise.
Well, if we have rx_errors containing any of the other more specific
error counts (reported in the net-stats struct), I don't see a reason
not to include all of them in the counter. I think my preference would
be to have rx_errors be every conceivable frame that we know was sent to
us but which did not get properly delivered to the software stack.
Each error would also fall into it's more specific counters.
That way, the rx-errors counter can be used for folks who just care
that the packet was not correctly received, and those that care about
the details can look at the individual errors (and sum them up in various
configurations due to personal taste, etc.)
That said, rx-errors would then be duplicate info because we could arrive
at it's value by just adding up all the other error counters....
> It does seem like a netdev stats clarification doc would be
> appropriate. Does anyone have the beginnings of this?
It's not authoritative, but I scrounged this info from various people,
including Mr Becker some years ago. I undoubtedly made some of this up
myself, and there could be errors of course:
rx_errors: Total of all rx errors
rx_dropped: Dropped on receive, usually due to kernel being over-worked.
rx_length: Dropped because pkt-length was invalid.
rx_over: Dropped because we over-ran the NIC's rx buffers.
rx_crc: Packets received with bad CRC errors.
rx_frame: Framing errors (errors at the physical layer), usually cable or hardware error.
rx_fifo: Dropped due to Kernel buffers being full (I guess rx-over could be NIC only, rx-fifo be kernel/driver only.)
rx_missed: Dropped due to not handling IRQ in time.
tx_abort: Failed to TX due to driver abort.
tx_carrier: Failed to TX due to lack of carrier signal.
tx_fifo: Over-ran the driver/kernel buffer(s).
tx_heartbeat: Failed to TX due to transceiver heartbeat errors.
tx_window: Failed to TX due to out-of-window error.
Thanks,
Ben
>
> John
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Daniele Orlandi @ 2005-10-24 22:58 UTC (permalink / raw)
To: netdev; +Cc: netdev
In-Reply-To: <20051024222222.GA11005@xi.wantstofly.org>
On Tuesday 25 October 2005 00:22, Lennert Buytenhek wrote:
>
> Your code might never end up in the kernel at all, for example if you
> ever lose interest in it. The situation that we'd like to avoid is
> ending up with reserved constants for code that was never submitted
> upstream at all.
Okay, I see your point.
IMHO I'd have preferred a more open politic like libpcap's. There may be valid
reasons to keep code out of the tree and this makes maintenance even harder
to perform than it already is.
Thanks anyway,
Bye,
--
Daniele Orlandi
^ permalink raw reply
* Re: 2.6.14-rc5 e1000 and page allocation failures.. still
From: Jesse Brandeburg @ 2005-10-24 22:28 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <435C2D66.6030708@shaw.ca>
On 10/23/05, Robert Hancock <hancockr@shaw.ca> wrote:
> John Bäckstrand wrote:
> > Im seeing a massive amount of page allocation failures with 2.6.14-rc5,
> > and also earlier kernels, see "E1000 - page allocation failure - saga
[snip]
> It looks like you have enough memory free - the problem is that the
> driver is allocating a block of memory with order 3, which is 8 pages.
> Quite likely there are not enough contiguous free pages to satisfy that.
>
> That's an awful big buffer size for a packet - I assume you're using
> jumbo frames or something? Ideally the driver and hardware should be
> able to allocate a buffer for those packets in multiple chunks, but I
> have no idea if this is possible.
the latest e1000 driver (6.2.15) from http://sf.net/projects/e1000
fixes this by using multiple descriptors for jumbo frames, therefore
only doing order 0 (single page) page allocations.
let us know how it goes.
BTW why is this so much more common with recent kernels?
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Andi Kleen @ 2005-10-24 22:24 UTC (permalink / raw)
To: Daniele Orlandi; +Cc: netdev, netdev
In-Reply-To: <200510242333.05366.daniele@orlandi.com>
On Monday 24 October 2005 23:33, Daniele Orlandi wrote:
>
> > Normally Linux doesn't pre-allocate ABIs for out of tree code, mostly
> > because it is not guaranteed that the interface won't change there.
>
> Could you clarify? What interface do you fear that could change?
Any interface implemented by your out of tree code for which you're
requesting to reserve constants.
-Andi
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Lennert Buytenhek @ 2005-10-24 22:22 UTC (permalink / raw)
To: Daniele Orlandi; +Cc: netdev, netdev
In-Reply-To: <200510250008.10409.daniele@orlandi.com>
On Tue, Oct 25, 2005 at 12:08:09AM +0200, Daniele Orlandi wrote:
> > First get your code in the kernel, then submit the patch to libpcap.
>
> Hopefully I will but currently vISDN is not mature enough to be
> evaluated for kernel inclusion.
>
> I would like to keep it out of the tree while it matures, however I
> would also like to avoid potential constants clashes with outher/future
> code.
>
> You may see the constants allocation as the first step to include that
> code in the kernel.
Your code might never end up in the kernel at all, for example if you
ever lose interest in it. The situation that we'd like to avoid is
ending up with reserved constants for code that was never submitted
upstream at all.
cheers,
Lennert
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Daniele Orlandi @ 2005-10-24 22:08 UTC (permalink / raw)
To: netdev; +Cc: netdev
In-Reply-To: <20051024215140.GA10872@xi.wantstofly.org>
On Monday 24 October 2005 23:51, Lennert Buytenhek wrote:
>
> First get your code in the kernel, then submit the patch to libpcap.
Hopefully I will but currently vISDN is not mature enough to be evaluated for
kernel inclusion.
I would like to keep it out of the tree while it matures, however I would also
like to avoid potential constants clashes with outher/future code.
You may see the constants allocation as the first step to include that code in
the kernel.
Bye,
--
Daniele Orlandi
^ permalink raw reply
* Re: [patch 2.6.13 0/5] normalize calculations of rx_dropped
From: John W. Linville @ 2005-10-24 21:57 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-kernel, netdev, Jeff Garzik
In-Reply-To: <435D53AE.3020401@candelatech.com>
On Mon, Oct 24, 2005 at 02:35:42PM -0700, Ben Greear wrote:
> It doesn't matter too much to me either way, but I'd like for there to
> be a precisely documented definition for the various net-stats so that
> I can correctly show the values to user-space (I can certainly add
> rx_discards
> to rx_errors for a 'total rx errors' value, but I need to know whether
> rx_discards is already in rx_errors to keep from counting things twice.)
My opinion is that:
-- rx_errors should count all "on the wire" hardware errors;
-- rx_missed_errors should count frames w/ no "on the wire"
errors that cannot be received by the hardware (generally
due to lack of DMA bufers); and,
-- rx_discards should count frames dropped by the kernel
after successful reception by the hardware.
I do _not_ think rx_missed_errors should be counted as part of
rx_errors, but I could be persuaded otherwise.
> Jeff: Could you lay down the law somewhere in the Documentation/
> directory and then let us start fixing any driver that does it differently?
It does seem like a netdev stats clarification doc would be
appropriate. Does anyone have the beginnings of this?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Lennert Buytenhek @ 2005-10-24 21:51 UTC (permalink / raw)
To: Daniele Orlandi; +Cc: netdev, netdev
In-Reply-To: <200510242333.05366.daniele@orlandi.com>
On Mon, Oct 24, 2005 at 11:33:04PM +0200, Daniele Orlandi wrote:
> My main concern is that without an ARPHRD_ constant guaranteed to be
> unique I wouldn't be able to propose a patch for libpcap people to map
> the (already allocated) DLT_ to the correct ARPHRD_.
First get your code in the kernel, then submit the patch to libpcap.
--L
^ permalink raw reply
* Re: [patch 2.6.13 0/5] normalize calculations of rx_dropped
From: Ben Greear @ 2005-10-24 21:35 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, Jeff Garzik
In-Reply-To: <20050912191419.GB19644@tuxdriver.com>
John W. Linville wrote:
> On Mon, Sep 12, 2005 at 02:53:31PM -0400, Jeff Garzik wrote:
>
>
>>For e.g. e1000, are we sure that packets dropped by hardware are
>>accounted elsewhere?
>
>
> The e100 and tg3 patches move the count of those frames to
> rx_missed_errors. e1000 and ixgb were already counting them there in
> addition to rx_discards, so they were simply removed from rx_discards.
> 3c59x was counting other errors in rx_discards, so they were removed
> from that count.
Whatever became of this discussion? It seems that the e1000 driver
in 2.6.13.2 uses rx_errors as the total of all receive errors, while
the patch John was proposing broke them out into separate counters.
It doesn't matter too much to me either way, but I'd like for there to
be a precisely documented definition for the various net-stats so that
I can correctly show the values to user-space (I can certainly add rx_discards
to rx_errors for a 'total rx errors' value, but I need to know whether
rx_discards is already in rx_errors to keep from counting things twice.)
Jeff: Could you lay down the law somewhere in the Documentation/
directory and then let us start fixing any driver that does it differently?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Request for an ARPHRD_
From: Daniele Orlandi @ 2005-10-24 21:33 UTC (permalink / raw)
To: netdev; +Cc: netdev
In-Reply-To: <200510241807.23290.ak@suse.de>
On Monday 24 October 2005 18:07, Andi Kleen wrote:
>
> ETH_P_* is managed by the IEEE (part of the ethernet standard) You would
> need to ask them.
I need a pseudo protocol like it is already done for some internal protocol,
e.g.:
/*
* Non DIX types. Won't clash for 1500 types.
*/
[.....]
#define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/
#define ETH_P_PPP_MP 0x0008 /* Dummy type for PPP MP frames */
#define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type */
#define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/
[....]
> Normally Linux doesn't pre-allocate ABIs for out of tree code, mostly
> because it is not guaranteed that the interface won't change there.
Could you clarify? What interface do you fear that could change?
My main concern is that without an ARPHRD_ constant guaranteed to be unique I
wouldn't be able to propose a patch for libpcap people to map the (already
allocated) DLT_ to the correct ARPHRD_.
Bye,
--
Daniele Orlandi
^ 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