* Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Jeff Garzik @ 2005-10-26 4:53 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Stephen Hemminger, Manfred Spraul, Netdev
In-Reply-To: <435D1464.3010203@nvidia.com>
Ayaz Abdulla wrote:
> Yes, forgot that indent.
>
> Here it is again with that fix.
I applied this version of the patch to the 'upstream' patch.
In the future, as Stephen noted, it would really be preferred that you
split up the patch into logical changes. patch 1/2 netdev_priv(), patch
2/2 SG support, for example.
Also, always include the Signed-off-by line, even on patch resends. See
http://linux.yyz.us/patch-format.html
for more info.
Jeff
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: James Morris @ 2005-10-26 4:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, Herbert Xu
In-Reply-To: <435EBC57.7090000@trash.net>
On Wed, 26 Oct 2005, Patrick McHardy wrote:
> No. I thought of this as a special case of inner transport mode SAs
> (without any further SAs) which would be unhandled. I've never used
> pure transport mode SAs except for testing, and I've never seen any
> other users of this. Do you think it is important to handle?
Pure transport mode SAs are likely to be common when using IPSec labeling
(the stuff Trent Jaeger has been working on).
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] kill massive wireless-related log spam
From: Jeff Garzik @ 2005-10-26 4:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: netdev, linux-kernel, jketreno, Andrew Morton
Please apply to 2.6.14-rc.
Although this message is having the intended effect of causing wireless
driver maintainers to upgrade their code, I never should have merged
this patch in its present form. Leading to tons of bug reports and
unhappy users.
Some wireless apps poll for statistics regularly, which leads to a
printk() every single time they ask for stats. That's a little bit
_too_ much of a reminder that the driver is using an old API.
Change this to printing out the message once, per kernel boot.
diff --git a/net/core/wireless.c b/net/core/wireless.c
index d17f158..271ddb3 100644
--- a/net/core/wireless.c
+++ b/net/core/wireless.c
@@ -455,10 +455,15 @@ static inline struct iw_statistics *get_
/* Old location, field to be removed in next WE */
if(dev->get_wireless_stats) {
- printk(KERN_DEBUG "%s (WE) : Driver using old /proc/net/wireless support, please fix driver !\n",
- dev->name);
+ static int printed_message;
+
+ if (!printed_message++)
+ printk(KERN_DEBUG "%s (WE) : Driver using old /proc/net/wireless support, please fix driver !\n",
+ dev->name);
+
return dev->get_wireless_stats(dev);
}
+
/* Not found */
return (struct iw_statistics *) NULL;
}
^ permalink raw reply related
* Re: [PATCH] 1/5 ibmveth fix bonding
From: Jeff Garzik @ 2005-10-26 4:11 UTC (permalink / raw)
To: Santiago Leon; +Cc: netdev, lkml
In-Reply-To: <1130275458.10524.425.camel@localhost.localdomain>
Santiago Leon wrote:
> 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>
all patches look OK to me.
all patches except #1 appear to be whitespace-corrupted.
Jeff
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Herbert Xu @ 2005-10-26 0:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel
In-Reply-To: <435EBC57.7090000@trash.net>
On Wed, Oct 26, 2005 at 01:14:31AM +0200, Patrick McHardy wrote:
> No. I thought of this as a special case of inner transport mode SAs
> (without any further SAs) which would be unhandled. I've never used
> pure transport mode SAs except for testing, and I've never seen any
> other users of this. Do you think it is important to handle?
Well the scenario is IPv4 transport mode ESP applied outside normal
IPIP tunnel devices.
Actually, this could work if we make sure that the user-space KMs
set the SA selectors properly in this case.
I presume that you will be changing the output path so that LOCAL_OUT
does not see the plain-text packet. Otherwise it'll be asymmetric with
repsect to the inbound side which does not see plain-text packets for
transport mode SAs.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Francois Romieu @ 2005-10-25 23:22 UTC (permalink / raw)
To: Michael Chan
Cc: Ayaz Abdulla, Stephen Hemminger, Jeff Garzik, Manfred Spraul,
Netdev
In-Reply-To: <1130272203.6236.2.camel@rh4>
Michael Chan <mchan@broadcom.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?
When the CPU sets the entries of a multi-descriptor packet, the first
descriptor is marked read while the next ones are still unset.
If any of BNX2_L2CTX_TX_HOST_{BIDX/BSEQ} prevents the asic to read
beyond 'prod' (or b(yte)seq ?), the ordering does not matter. Right ?
--
Ueimor
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-25 23:14 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <20051025231049.GA13679@gondor.apana.org.au>
Herbert Xu wrote:
> On Wed, Oct 26, 2005 at 01:09:12AM +0200, Patrick McHardy wrote:
>
>>>So how about this? We let the SA tell us whether they want to go through
>>>netfilter again. So each SA will carry a flag which determines whether
>>>packets through it should go through netfilter.
>>>
>>>This flag would only affect transport mode SAs of course.
>>
>>That would be one possibility. But I'm not a big fan of per-state flags
>>that affect packet flow, so I think I'd prefer to just ignore this
>>case. I don't think not handling inner transport mode SAs would be a
>>big loss, so how about we just skip inner transport mode SAs completely
>>on output and keep the input code as it is?
>
>
> Actually I was thinking of transport mode SAs with no accompanying
> tunnel mode SAs. Did you have another way of dealing with them?
No. I thought of this as a special case of inner transport mode SAs
(without any further SAs) which would be unhandled. I've never used
pure transport mode SAs except for testing, and I've never seen any
other users of this. Do you think it is important to handle?
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Herbert Xu @ 2005-10-25 23:10 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel
In-Reply-To: <435EBB18.50701@trash.net>
On Wed, Oct 26, 2005 at 01:09:12AM +0200, Patrick McHardy wrote:
>
> > So how about this? We let the SA tell us whether they want to go through
> > netfilter again. So each SA will carry a flag which determines whether
> > packets through it should go through netfilter.
> >
> > This flag would only affect transport mode SAs of course.
>
> That would be one possibility. But I'm not a big fan of per-state flags
> that affect packet flow, so I think I'd prefer to just ignore this
> case. I don't think not handling inner transport mode SAs would be a
> big loss, so how about we just skip inner transport mode SAs completely
> on output and keep the input code as it is?
Actually I was thinking of transport mode SAs with no accompanying
tunnel mode SAs. Did you have another way of dealing with them?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-25 23:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <20051017014629.GB32661@gondor.apana.org.au>
Sorry for the huge delay Herbert, I really appreciate your input,
but I'm stuck in other work.
Herbert Xu wrote:
> I can see the concern of processing pure transport mode packets in IPv6
> twice in the stack because IPsec in IPv6 is used for a totally different
> purpose compared to IPv4.
>
> So how about this? We let the SA tell us whether they want to go through
> netfilter again. So each SA will carry a flag which determines whether
> packets through it should go through netfilter.
>
> This flag would only affect transport mode SAs of course.
That would be one possibility. But I'm not a big fan of per-state flags
that affect packet flow, so I think I'd prefer to just ignore this
case. I don't think not handling inner transport mode SAs would be a
big loss, so how about we just skip inner transport mode SAs completely
on output and keep the input code as it is?
Regards
Patrick
^ permalink raw reply
* Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Michael Chan @ 2005-10-25 22:05 UTC (permalink / raw)
To: Francois Romieu
Cc: Ayaz Abdulla, Stephen Hemminger, Jeff Garzik, Manfred Spraul,
Netdev
In-Reply-To: <20051025232248.GB17794@electric-eye.fr.zoreil.com>
On Wed, 2005-10-26 at 01:22 +0200, Francois Romieu wrote:
> Michael Chan <mchan@broadcom.com> :
> > Please explain what did you mean by bogus?
>
> When the CPU sets the entries of a multi-descriptor packet, the first
> descriptor is marked read while the next ones are still unset.
>
Not sure you you meant by "marked read", but none of the new tx
descriptors will be DMA'ed by the chip until we write the producer index
and the byte seq. number.
> If any of BNX2_L2CTX_TX_HOST_{BIDX/BSEQ} prevents the asic to read
> beyond 'prod' (or b(yte)seq ?), the ordering does not matter. Right ?
>
Right, the chip will only DMA the tx descriptors up to the (prod - 1)
index. tg3 works in a similar way.
^ permalink raw reply
* 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
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