* Re: <REAL> iBurst (TM) compatible driver
From: Andi Kleen @ 2005-10-27 17:44 UTC (permalink / raw)
To: John W. Linville; +Cc: Nicholas Jefferson, netdev, linux-kernel
In-Reply-To: <20051027170727.GA26569@tuxdriver.com>
On Thursday 27 October 2005 19:07, John W. Linville wrote:
> On Fri, Oct 28, 2005 at 02:24:20AM +1000, Nicholas Jefferson wrote:
> > The latest release of the iBurst (TM) compatible driver [1] for the
> > 2.6 kernel is now available. Thanks to ArrayComm (R) for the original
>
> <snip>
>
> > Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
>
> -ENOPATCH?
And no description what an "iBurst (tm)" actually is. It sounds like
something to clear blocked drains with.
-Andi
^ permalink raw reply
* Re: [PATCH] kill massive wireless-related log spam
From: Horst von Brand @ 2005-10-27 17:37 UTC (permalink / raw)
To: Jeff Garzik
Cc: Andi Kleen, Linus Torvalds, netdev, linux-kernel, jketreno,
Andrew Morton
In-Reply-To: <435FA3FB.9030107@pobox.com>
Jeff Garzik <jgarzik@pobox.com> wrote:
> 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.
Right. As the "++" is inside "if(!printed) { ... }" it clearly isn't ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: <REAL> iBurst (TM) compatible driver
From: John W. Linville @ 2005-10-27 17:07 UTC (permalink / raw)
To: Nicholas Jefferson; +Cc: netdev, linux-kernel
In-Reply-To: <4cd031a50510270924r38ad4d5oa88ae92a514df3cf@mail.gmail.com>
On Fri, Oct 28, 2005 at 02:24:20AM +1000, Nicholas Jefferson wrote:
> The latest release of the iBurst (TM) compatible driver [1] for the
> 2.6 kernel is now available. Thanks to ArrayComm (R) for the original
<snip>
> Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
-ENOPATCH?
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-27 16:58 UTC (permalink / raw)
To: yoshifuji; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <20051027.235732.01166239.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[ wrote:
> In article <20051027121545.GA5530@gondor.apana.org.au> (at Thu, 27 Oct 2005 22:15:45 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
>
>
>>On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>>
>>>Stack should process the packet just once if it is of transport mode.
>>>(It is okay to process one twice if it is of tunnel mode.)
>>
>>Thinking about this again, I'm not sure that I agree.
>>
>>OK, I don't actually care whether we process it once or twice for
>>pure transport mode, but I think that it is absolutely essential
>>that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
>>the encrypted version.
>
>
> Well, I really care.
> I strongly believe that we SHOULD NOT mix encrypted
> packets and plain text packets at the same hook.
> e.g. LOCAL_IN is NOT for decrypted plain text packets,
> but for the original encrypted ones.
It is in tunnel mode. LOCAL_IN is for all packets that are
locally delivered, independant of encryption. Using new
hooks for decrypted transport mode packets is inconsistent
IMO.
> I believe that we should have another set of hooks
> after decryption (other than LOCAL_IN) if we want to
> look inside the encrypted packets.
This isn't possible without adding completely new tables since
we can't add new chains to existing tables without breaking
userspace compatiblity. If we want existing functionality to
continue working we would need an "xfrm" version of the raw,
mangle, nat and filter table and need to change conntrack (and
possibly NAT) to use the new hooks. Rerouting after NAT (with IPv4)
won't work if we don't pass the packet through the stack again.
I think adding new hooks has too many drawbacks compared to simply
sending the decrypted packet through the stack again.
^ permalink raw reply
* <REAL> iBurst (TM) compatible driver
From: Nicholas Jefferson @ 2005-10-27 16:24 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The latest release of the iBurst (TM) compatible driver [1] for the
2.6 kernel is now available. Thanks to ArrayComm (R) for the original
code under the GPL, and Personal Broadband Australia (PBA) and
Independent Service Providers Australia (ISP) for support. Special
thanks to developers David Barr and Nik Trevallyn-Jones.
[1] http://sourceforge.net/projects/ibdriver
Disclaimer: This driver was not written by ArrayComm (R) and it is not
supported by them. This driver is distributed in the hope that it will
be useful, but without any warranty; without even the implied warranty
of merchantability or fitness for a particular purpose.
Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
Kind regards,
Nicholas
^ permalink raw reply
* iBurst (TM) compatible driver
From: Nicholas Jefferson @ 2005-10-27 15:47 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
The latest release of the iBurst (TM) compatible driver [1] for the
2.6 kernel is now available. Thanks to ArrayComm (R) for the original
code under the GPL, and Personal Broadband Australia (PBA) and
Independent Service Providers Australia (ISP) for support. Special
thanks to developers David Barr and Nik Trevallyn-Jones.
[1] http://sourceforge.net/projects/ibdriver
Disclaimer: This driver was not written by ArrayComm (R) and it is not
supported by them. This driver is distributed in the hope that it will
be useful, but without any warranty; without even the implied warranty
of merchantability or fitness for a particular purpose.
Signed-off-by: Nicholas Jefferson <xanthophile@gmail.com>
Kind regards,
Nicholas
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-10-27 14:57 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051027121545.GA5530@gondor.apana.org.au>
In article <20051027121545.GA5530@gondor.apana.org.au> (at Thu, 27 Oct 2005 22:15:45 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:
> On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> >
> > Stack should process the packet just once if it is of transport mode.
> > (It is okay to process one twice if it is of tunnel mode.)
>
> Thinking about this again, I'm not sure that I agree.
>
> OK, I don't actually care whether we process it once or twice for
> pure transport mode, but I think that it is absolutely essential
> that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
> the encrypted version.
Well, I really care.
I strongly believe that we SHOULD NOT mix encrypted
packets and plain text packets at the same hook.
e.g. LOCAL_IN is NOT for decrypted plain text packets,
but for the original encrypted ones.
I believe that we should have another set of hooks
after decryption (other than LOCAL_IN) if we want to
look inside the encrypted packets.
--yoshfuji
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-10-27 14:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <20051026003954.GA14068@gondor.apana.org.au>
Herbert Xu wrote:
> 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.
Yes, that was the idea. But since people seem to consider this an
important case to handle I'm going to try the per-SA flag you
proposed. I'll send new patches in the next days.
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Herbert Xu @ 2005-10-27 12:15 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051017.094919.56989341.yoshfuji@linux-ipv6.org>
On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Stack should process the packet just once if it is of transport mode.
> (It is okay to process one twice if it is of tunnel mode.)
Thinking about this again, I'm not sure that I agree.
OK, I don't actually care whether we process it once or twice for
pure transport mode, but I think that it is absolutely essential
that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
the encrypted version.
Whether it's IPv4 or IPv6, transport mode shouldn't make you lose the
ability to use netfilter to filter out packets.
Now if we can achieve this by sending the packet through netfilter
only once then I'm all for it.
But if for whatever reason we can't do that, then I'd rather have it
go through twice than not see the decapsulated packet at all which is
the case at the moment.
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] kill massive wireless-related log spam
From: Jesper Juhl @ 2005-10-26 21:43 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Linux-Kernel, netdev
In-Reply-To: <AB480DAC-57B0-4125-8BA5-D6C715B693B6@able.es>
On 10/26/05, J.A. Magallon <jamagallon@able.es> wrote:
>
> 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 ?
>
Does it really matter? I needed to pick one of
printed_message=1; or printed_message++;
the end result is the same, so I just picked one at random.
But now that you mention it, I guess ++ would turn into "inc" which
should be faster than an assignment... but it *doesn't matter*... I
was not trying to optimize anything, just make the code work properly
- as in, only ever print the message once...
--
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: 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
* 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
* [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
* [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 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 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 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 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
* 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
* 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: 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: [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: [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: [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: [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
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