* 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
* 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: [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: [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: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: [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: 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] 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
* [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: [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
* 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: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support
From: Ayaz Abdulla @ 2005-10-26 6:17 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Stephen Hemminger, Manfred Spraul, Netdev
Thanks.
I will resend version 45 (bug fix) and 46 (irq modes) since they will
need new modifications based on the changes made in this patch and the
comments you suggested.
-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@pobox.com]
Sent: Tuesday, October 25, 2005 9:53 PM
To: Ayaz Abdulla
Cc: Stephen Hemminger; Manfred Spraul; Netdev
Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation
offload support
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: Ingo Oeser @ 2005-10-26 7:37 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, Herbert Xu
In-Reply-To: <435EBC57.7090000@trash.net>
Patrick McHardy wrote:
> Herbert Xu wrote:
> > 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?
These become important in untrusted LANs. These days, the LAN is often
not safe enough for confidental data, so you need end to end encryption,
for which tunnel mode is a bitch to setup (due to the additional routing
required ).
Regards
Ingo Oeser
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Stephen Frost @ 2005-10-26 13:37 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, Herbert Xu
In-Reply-To: <435EBC57.7090000@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
* Patrick McHardy (kaber@trash.net) wrote:
> Herbert Xu wrote:
> > 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?
I've used pure transport mode SAs in a couple of cases and I do feel
they're important to support, and would really like to be able to use
firewall rules with them too.. In fact, I'd think it'd be more
important with transport-mode because it's more likely you'll want to
set up a pretty open use-ipsec-whenever-possible-with-remote-hosts mode,
unlike with tunnel mode where it's more likely you'll set up specific
policies which only accept tunnels which go to certain ports on certain
IPs, etc. At least, I've set that up as well... :)
Thanks,
Stephen
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Andi Kleen @ 2005-10-26 15:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linus Torvalds, netdev, linux-kernel, jketreno, Andrew Morton
In-Reply-To: <20051026042827.GA22836@havoc.gtf.org>
On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
> Change this to printing out the message once, per kernel boot.
It doesn't do that. It prints it once every 2^32 calls. Also
the ++ causes unnecessary dirty cache lines in normal operation.
-Andi
>
> 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);
> }
> +
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Jesper Juhl @ 2005-10-26 15:23 UTC (permalink / raw)
To: Andi Kleen
Cc: Jeff Garzik, Linus Torvalds, netdev, linux-kernel, jketreno,
Andrew Morton
In-Reply-To: <200510261704.15366.ak@suse.de>
On 10/26/05, Andi Kleen <ak@suse.de> wrote:
> On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
>
> > Change this to printing out the message once, per kernel boot.
>
> It doesn't do that. It prints it once every 2^32 calls. Also
I noted that as well. How about just using something along the lines of
static unsigned char printed_message = 0;
if (!printed_message) {
printk(...);
printed_message++;
}
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Jeff Garzik @ 2005-10-26 15:42 UTC (permalink / raw)
To: Andi Kleen; +Cc: Linus Torvalds, netdev, linux-kernel, jketreno, Andrew Morton
In-Reply-To: <200510261704.15366.ak@suse.de>
Andi Kleen wrote:
> On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
>
>
>>Change this to printing out the message once, per kernel boot.
>
>
> It doesn't do that. It prints it once every 2^32 calls. Also
...which is effectively one per kernel boot
> the ++ causes unnecessary dirty cache lines in normal operation.
Not a hot path operation by any stretch of the imagination, so that's fine.
Jeff
^ permalink raw reply
* [PATCH 0/5] ibmveth resending various fixes
From: Santiago Leon @ 2005-10-26 16:46 UTC (permalink / raw)
To: Andrew Morton, lkml, netdev; +Cc: Santiago Leon, Jeff Garzik
Resending various ibmveth fixes due to wordwrapping by email client.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
^ permalink raw reply
* [PATCH 1/5] ibmveth fix bonding
From: Santiago Leon @ 2005-10-26 16:46 UTC (permalink / raw)
To: Andrew Morton, netdev, lkml; +Cc: Santiago Leon, Jeff Garzik
In-Reply-To: <20051026164532.21820.72673.sendpatchset@localhost.localdomain>
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(+)
--- 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;
^ permalink raw reply
* [PATCH 2/5] ibmveth fix buffer pool management
From: Santiago Leon @ 2005-10-26 16:47 UTC (permalink / raw)
To: Andrew Morton, lkml, netdev; +Cc: Santiago Leon, Jeff Garzik
In-Reply-To: <20051026164532.21820.72673.sendpatchset@localhost.localdomain>
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(-)
--- 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 {
^ permalink raw reply
* [PATCH 3/5] ibmveth fix buffer replenishing
From: Santiago Leon @ 2005-10-26 16:47 UTC (permalink / raw)
To: Andrew Morton, netdev, lkml; +Cc: Santiago Leon, Jeff Garzik
In-Reply-To: <20051026164532.21820.72673.sendpatchset@localhost.localdomain>
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(-)
--- 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;
^ permalink raw reply
* [PATCH 4/5] ibmveth lockless TX
From: Santiago Leon @ 2005-10-26 16:47 UTC (permalink / raw)
To: Andrew Morton, lkml, netdev; +Cc: Santiago Leon, Jeff Garzik
In-Reply-To: <20051026164532.21820.72673.sendpatchset@localhost.localdomain>
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(-)
--- 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 {
^ permalink raw reply
* [PATCH 5/5] ibmveth fix failed addbuf
From: Santiago Leon @ 2005-10-26 16:47 UTC (permalink / raw)
To: Andrew Morton, netdev, lkml; +Cc: Santiago Leon, Jeff Garzik
In-Reply-To: <20051026164532.21820.72673.sendpatchset@localhost.localdomain>
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(-)
--- 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,
^ permalink raw reply
* To James Ketrenos
From: Jean Tourrilhes @ 2005-10-26 17:52 UTC (permalink / raw)
To: netdev, ipw2100-devel; +Cc: Jeff Garzik, Dan Williams
James,
Would you mind fixing the mail system on your side ? Other
people never had trouble receiving e-mail from me. Otherwise, I'll
just have to ask people to forward you my e-mails...
Thanks in advance...
Jean
----- Forwarded message from Mail Delivery System <MAILER-DAEMON@janus0.fc.hp.com> -----
Delivery-date: Wed, 26 Oct 2005 10:46:41 -0700
Subject: Undelivered Mail Returned to Sender
Content-Description: Notification
This is the Postfix program at host janus0.fc.hp.com.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<jketreno@linux.intel.com>: host 192.55.36.23[192.55.36.23] said: 550
jketreno@linux.intel.com ...Relaying denied (in reply to RCPT TO command)
Content-Description: Delivery error report
Reporting-MTA: dns; janus0.fc.hp.com
Arrival-Date: Wed, 26 Oct 2005 11:46:36 -0600 (MDT)
Final-Recipient: rfc822; jketreno@linux.intel.com
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host 192.55.36.23[192.55.36.23] said: 550
jketreno@linux.intel.com ...Relaying denied (in reply to RCPT TO command)
Content-Description: Undelivered Message
Subject: Re: Wireless scanning and EAGAIN
E-mail: jt@hpl.hp.com
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: J.A. Magallon @ 2005-10-26 21:23 UTC (permalink / raw)
To: Linux-Kernel; +Cc: netdev
In-Reply-To: <9a8748490510260823s681a4d82k5efa5734486eda85@mail.gmail.com>
On 2005.10.26, at 17:23, Jesper Juhl wrote:
> On 10/26/05, Andi Kleen <ak@suse.de> wrote:
>
>> On Wednesday 26 October 2005 06:28, Jeff Garzik wrote:
>>
>>
>>> Change this to printing out the message once, per kernel boot.
>>>
>>
>> It doesn't do that. It prints it once every 2^32 calls. Also
>>
>
> I noted that as well. How about just using something along the
> lines of
>
> static unsigned char printed_message = 0;
> if (!printed_message) {
> printk(...);
> printed_message++;
> }
Sorry, but why not the old good
printed_message = 1
??
What kind of microoptimization is that ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
wolverine \ It's better when it's free
MacOS X 10.4.2, Darwin Kernel Version 8.2.0
^ 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