On Mon, Mar 06, 2006 at 06:44:07PM +0100, Ingo Oeser ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov wrote:
> > On Sat, Mar 04, 2006 at 01:41:44PM -0800, David S. Miller ([EMAIL
> > PROTECTED]) wrote:
> > > From: Jan Engelhardt <[EMAIL PROTECTED]>
> > > Date: Sat, 4 Mar 2006 19:46:22 +0100 (MET)
> >
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 21:44:50 -0800
> Roland> struct neigh_ops currently has a destructor field, which
> Roland> no in-kernel drivers outside of infiniband use.
>
> Andrew> net/atm/clip.c begs to disagree.
>
> err... my fault for trusting the
Andrew> I'm also wondering why a combination of the net and
Andrew> infiniband trees does this:
Andrew> drivers/infiniband/ulp/ipoib/ipoib_multicast.c: In
Andrew> function `ipoib_mcast_free':
Andrew> drivers/infiniband/ulp/ipoib/ipoib_multicast.c:118: error:
Andrew> structu
Roland> struct neigh_ops currently has a destructor field, which
Roland> no in-kernel drivers outside of infiniband use.
Andrew> net/atm/clip.c begs to disagree.
err... my fault for trusting the patch changelog and not
double-checking. I think the fix is as simple as, although, given
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-03-07 05:11]:
> * Francois Romieu <[EMAIL PROTECTED]> [2006-03-06 22:17]:
> > Not sure about this one, but...
>
> It seems to help. It's hard to say for sure because I don't have a
> foolproof way to reproduce this panic. It _usually_ occurs after
> c
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> struct neigh_ops currently has a destructor field, which no in-kernel
> drivers outside of infiniband use.
net/atm/clip.c begs to disagree.
I'm also wondering why a combination of the net and infiniband trees does this:
drivers/infiniband/ulp/ipoib/i
* Francois Romieu <[EMAIL PROTECTED]> [2006-03-06 21:54]:
> > By the way, I'm getting the following messages in dmesg:
> > eth0: tx err, status 0x7fffb002
> Tx underrun.
> Is there anything which could induce a noticeable load on the PCI bus ?
I was going to say "no" because I was simply copying s
* Francois Romieu <[EMAIL PROTECTED]> [2006-03-06 22:17]:
> Not sure about this one, but...
It seems to help. It's hard to say for sure because I don't have a
foolproof way to reproduce this panic. It _usually_ occurs after
copying a few hundred MB but there's no clear trigger. I've now copied
Chen, Kenneth W wrote:
Nick Piggin wrote on Monday, March 06, 2006 6:05 PM
My patches in -mm avoid the lru_lock and disabling/enabling interrupts
if the page is not on lru too, btw.
Can you put the spin lock/unlock inside TestClearPageLRU()? The
difference is subtle though.
That's the id
Benjamin LaHaise wrote:
On Tue, Mar 07, 2006 at 01:04:36PM +1100, Nick Piggin wrote:
I'd say it will turn out to be more trouble than its worth, for the
miserly cost
avoiding one atomic_inc, and one atomic_dec_and_test on page-local data
that will
be in L1 cache. I'd never turn my nose up at a
On Tue, Mar 07, 2006 at 12:15:30AM +0100, Francois Romieu wrote:
> [...]
> > Does anyone have comments regarding this patch? I received
> > confirmation from a number of Debian users that this patch
> > significantly improves the lockup situation on Cobalt, so
> > it would be nice if it could go
Nick Piggin wrote on Monday, March 06, 2006 6:05 PM
>
> My patches in -mm avoid the lru_lock and disabling/enabling interrupts
> if the page is not on lru too, btw.
Can you put the spin lock/unlock inside TestClearPageLRU()? The
difference is subtle though.
- Ken
--- ./mm/swap.c.orig2006-
On Tue, Mar 07, 2006 at 01:04:36PM +1100, Nick Piggin wrote:
> I'd say it will turn out to be more trouble than its worth, for the
> miserly cost
> avoiding one atomic_inc, and one atomic_dec_and_test on page-local data
> that will
> be in L1 cache. I'd never turn my nose up at anyone just having
Benjamin LaHaise wrote:
On Tue, Mar 07, 2006 at 12:53:27PM +1100, Nick Piggin wrote:
You can't do this because you can't test PageLRU like that.
Have a look in the lkml archives a few months back, where I proposed
a way to do this for __free_pages(). You can't do it for put_page.
Even if w
On Tue, Mar 07, 2006 at 12:53:27PM +1100, Nick Piggin wrote:
> You can't do this because you can't test PageLRU like that.
>
> Have a look in the lkml archives a few months back, where I proposed
> a way to do this for __free_pages(). You can't do it for put_page.
Even if we know that we are the
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6177
>
>Summary: Java remote debugging is slow due to apparent networking
> bug
> Kernel Version: 2.6.15
> Status: NEW
> Severity: normal
> Owner: [EMAIL P
Benjamin LaHaise wrote:
On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
Am a bit surprised at those numbers.
Because userspace has to do peculiar things to get its pages taken off the
LRU. What exactly was that application doing?
It's just a simple send() and recv() pair
On Mon, Mar 06, 2006 at 05:39:41PM -0800, Andrew Morton wrote:
> > It's just a simple send() and recv() pair of processes. Networking uses
> > pages for the buffer on user transmits.
>
> You mean non-zero-copy transmits? If they were zero-copy then those pages
> would still be on the LRU.
Corr
Benjamin LaHaise wrote:
Hello Andrew et al,
The patch below adds a fast path that avoids the atomic dec and test
operation and spinlock acquire/release on page free. This is especially
important to the network stack which uses put_page() to free user
buffers. Removing these atomic ops help
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
> > Am a bit surprised at those numbers.
>
> > Because userspace has to do peculiar things to get its pages taken off the
> > LRU. What exactly was that application doing?
>
> It's just
On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
> Am a bit surprised at those numbers.
> Because userspace has to do peculiar things to get its pages taken off the
> LRU. What exactly was that application doing?
It's just a simple send() and recv() pair of processes. Networking u
Andrew Morton wrote:
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
Hello Andrew et al,
The patch below adds a fast path that avoids the atomic dec and test
operation and spinlock acquire/release on page free. This is especially
important to the network stack which uses put_page() to free user
On Mon, 2006-03-06 at 16:52 -0800, David S. Miller wrote:
>
> Ok, so the >40-bit capable chips won't hit the "5780 class" code path?
>
The mask will be set to 40-bit for 5780 class only. In
tg3_start_xmit_dma_bug(), there is a 40-bit DMA address check for 5780
class only and will return 0 for a
On Mon, Mar 06, 2006 at 04:25:32PM -0800, David S. Miller wrote:
> Wait...
>
> what about "test_and_clear_bit()"?
>
> Most implementations should be doing the light-weight test _first_,
> and only do the update if the bit isn't in the state desired.
>
> I think in such cases we can elide the mem
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 15:07:50 -0800
> On Mon, 2006-03-06 at 16:39 -0800, David S. Miller wrote:
>
> > Also, you should probably fixup the DMA masks we use
> > if this chip really doesn't have the 40-bit limitation.
> > Or did you take care of that and I
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 16:52:41 -0800 (PST)
> I did put that patch in already.
Actually, no I didn't, it's still in my queue sorry.
I'll try to get to it tonight, it belongs in 2.6.16
for sure.
-
To unsubscribe from this list: send the line "unsubscrib
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
>
> Hello Andrew et al,
>
> The patch below adds a fast path that avoids the atomic dec and test
> operation and spinlock acquire/release on page free. This is especially
> important to the network stack which uses put_page() to free user
> buffers.
On Mon, 2006-03-06 at 16:39 -0800, David S. Miller wrote:
> Also, you should probably fixup the DMA masks we use
> if this chip really doesn't have the 40-bit limitation.
> Or did you take care of that and I missed it somehow?
>
The 40-bit stuff is handled in another patch, probably still in your
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:53:51 -0800
> Update version to 3.52.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Also applied, thanks a lot Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:53:18 -0800
> Add fw_version information to ethtool -i.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:52:54 -0800
> Some nvram related cleanup:
>
> 1. Add a tg3_nvram_read_swab() since swabing the data is frequently
> done.
>
> 2. Add a function to convert nvram address to physical address
> instead of doing it in 2 separate plac
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:51:54 -0800
> Support one-shot MSI on 5787.
>
> This one-shot MSI idea is credited to David Miller. In this mode, MSI
> disables itself automatically after it is generated, saving the driver
> a register access to disable it for N
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:50:51 -0800
> Support 5787 hardware TSO using a new flag TG3_FLG2_HW_TSO_2.
>
> Since the TSO interface is slightly different and these chips have
> finally fixed the 4GB DMA problem and do not have the 40-bit DMA
> problem, a new
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:51:22 -0800
> Support ipv6 tx csum on 5787 by setting NETIF_F_HW_CSUM.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mess
Ok, I found what I was talking about on irc...
Andy Fleming wrote a proper PHY layer, initially based on sungem_phy but
then evolved into something more versatile including some of the link
state machine that is currently still in the MAC driver for sungem.
You should probably use that...
It's a
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:50:22 -0800
> Support additional nvrams and new nvram format for 5787 and 5754.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied, but I had to remove trailing whitespace in the
patch by hand, as GIT warns about that no
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:49:54 -0800
> Add basic support for 2 new chips 5787 and 5754.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 16:09:07 -0800
> I'll respin it with the
> fast_clear_bit() suggestion.
Please see my other email first, we may be able to do something
even better via test_and_*_bit().
-
To unsubscribe from this list: send the line "unsubscribe n
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 15:40:31 -0800
> On Mon, Mar 06, 2006 at 08:29:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > - clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
> > + if (test_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags))
> > +
On Mon, Mar 06, 2006 at 03:23:04PM -0800, Jouni Malinen wrote:
> On Mon, Mar 06, 2006 at 02:25:52PM -0800, Jean Tourrilhes wrote:
> > Jouni Malinen wrote :
> > > This is used to implement radio on/off without having to change other
> > > parts of the configuration (e.g., set interfaces down).
>
>
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 15:40:56 -0800
> and 32 threads are probably good for flushing out SMP races.
Indeed, guess what I've been spending most of my time working
on lately? :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
On Tue, Mar 07, 2006 at 12:59:17AM +0100, Eric Dumazet wrote:
> I'm not even sure this 'optimization' is valid on UP.
It can be, as branch prediction makes the test essentially free. The real
answer is that it depends on the CPU, how much pressure there is on the write
combining buffers and reo
Bryan> Depends on the driver. Ours needs the interrupt vector
Bryan> rather than the number, which means we don't work without
Bryan> CONFIG_PCI_MSI. That is, unless there's some other way to
Bryan> get the vector that I don't know about (entirely likely).
OK, fair enough. But t
On Mon, 2006-03-06 at 15:40 -0800, Roland Dreier wrote:
> Anyway IB works fine with standard INTx interrupts -- MSI is just icing.
Depends on the driver. Ours needs the interrupt vector rather than the
number, which means we don't work without CONFIG_PCI_MSI. That is,
unless there's some other
Arnaldo Carvalho de Melo a écrit :
On 3/6/06, David S. Miller <[EMAIL PROTECTED]> wrote:
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 15:06:41 -0800
This patch removes a couple of memory barriers from atomic bitops that
showed up on profiles of netperf.
A little ugly, we s
On Tue, Mar 07, 2006 at 12:48:23AM +0100, Eric Dumazet wrote:
> If I understand your patch correctly, your future plan is to change "struct
> inet_ehash_bucket" rwlock_t wlock to a pure spinlock (when ipv6 is
> converted to rcu lookups too), because no more read_lock() are expected ?
Yes/no... T
On Mon, Mar 06, 2006 at 08:29:30PM -0300, Arnaldo Carvalho de Melo wrote:
> - clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
> + if (test_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags))
> + clear_bit(SOCK_ASYNC_NOSPACE, &sk->sk_socket->flags);
>
> Something like fa
Benjamin LaHaise a écrit :
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit whe
Roland> I should look into getting some niagara machines to test
Roland> with -- with PCIe slots they should actually be good for
Roland> IB testing.
David> You'll be cpu limited until we have Van Jacobson net
David> channels.
For IPoIB maybe but not for native IB which offloa
Kernel mode connection management agent over Infiniband that connects based
on IP addresses. The agent defines a generic RDMA connection abstraction
to support clients wanting to connect over different RDMA devices.
Agent also handles RDMA device hotplug events on behalf of clients.
Signed-off-b
Kernel component necessary to support the userspace RDMA connection management
library.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Discussion on the list suggested giving the userspace interface more time to
develop, which seems reasonable.
diff -uprN -X linux-2.6.git/Documentation/dontd
Support ipv6 tx csum on 5787 by setting NETIF_F_HW_CSUM.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 3e7eb3d..8560f58 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7871,10 +7871,10 @@ static int tg3_set_tx_csum(struct net_
Add fw_version information to ethtool -i.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 1a35dbe..dd545b0 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7666,6 +7666,7 @@ static void tg3_get_drvinfo(struct net_d
st
Some nvram related cleanup:
1. Add a tg3_nvram_read_swab() since swabing the data is frequently
done.
2. Add a function to convert nvram address to physical address
instead of doing it in 2 separate places.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/driver
In article <[EMAIL PROTECTED]> (at Mon, 06 Mar 2006 21:50:33 +0100),
Jean-Mickael Guerin <[EMAIL PROTECTED]> says:
> Hi,
>
> This patch fixes potential null pointer dereference (I never experiment
> such crash).
> The patch is made for net-2.6.17.
I disagree.
It never happen, because (void *)
Support 5787 hardware TSO using a new flag TG3_FLG2_HW_TSO_2.
Since the TSO interface is slightly different and these chips have
finally fixed the 4GB DMA problem and do not have the 40-bit DMA
problem, a new hard_start_xmit is used for these chips. All previous
chips will use the old hard_start_x
Support additional nvrams and new nvram format for 5787 and 5754.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b24408a..67de9f8 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -7816,29 +7816,53 @@ static void tg3_get_ethtool_s
Add basic support for 2 new chips 5787 and 5754.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 683d979..b24408a 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -221,6 +221,14 @@ static struct pci_device_id tg3_pci_tbl[
Support one-shot MSI on 5787.
This one-shot MSI idea is credited to David Miller. In this mode, MSI
disables itself automatically after it is generated, saving the driver
a register access to disable it for NAPI.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/d
Add an address translation service that maps IP addresses to Infiniband
GID addresses using IPoIB.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
This should be the correct patch. The only difference between this and the
mis-post
is the use of mutex_lock/unlock in place of up/down.
diff -
Extend matching connection requests to listens in the Infiniband CM to include
private data checks.
This allows applications to listen on the same service identifier, with private
data directing the request to the appropriate application.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
This s
On 3/6/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Benjamin LaHaise <[EMAIL PROTECTED]>
> Date: Mon, 6 Mar 2006 15:06:41 -0800
>
> > This patch removes a couple of memory barriers from atomic bitops that
> > showed up on profiles of netperf.
>
> A little ugly, we should have a nicer way
On Mon, Mar 06, 2006 at 02:25:52PM -0800, Jean Tourrilhes wrote:
> Jouni Malinen wrote :
> > This is used to implement radio on/off without having to change other
> > parts of the configuration (e.g., set interfaces down).
> The airo driver use 'txpower' for that. txpower has a 'off'
> optio
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 15:06:41 -0800
> This patch removes a couple of memory barriers from atomic bitops that
> showed up on profiles of netperf.
A little ugly, we should have a nicer way to do this
generically.
-
To unsubscribe from this list: send the
This patch removes a couple of memory barriers from atomic bitops that
showed up on profiles of netperf.
-ben
Signed-off-by: Benjamin LaHaise <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 00aa80e..dadc84c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@
Martin Michlmayr <[EMAIL PROTECTED]> :
[...]
> Does anyone have comments regarding this patch? I received
> confirmation from a number of Debian users that this patch
> significantly improves the lockup situation on Cobalt, so
> it would be nice if it could go in.
I'll queue it with the pending d
Am Monday 06 March 2006 23:07 schrieb Andrew Morton:
> Jens Osterkamp <[EMAIL PROTECTED]> wrote:
> > Which kernel version was this in ? 2.6.16-rc5 builds ok for me.
> >
> > drivers/net/spider_net.c:421: multiple definition of `mii_phy_probe'
> > drivers/net/sungem_phy.o(.opd+0x160):drivers/net/sung
On Tue, 7 Mar 2006 00:34:38 +0200
"Michael S. Tsirkin" <[EMAIL PROTECTED]> wrote:
> Hello, Dave!
> As you might know, the TSO patches merged into mainline kernel
> since 2.6.11 have hurt performance for the simple (non-TSO)
> high-speed netdevice that is IPoIB driver.
>
> This was discussed at le
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 14:41:21 -0800
> I should look into getting some niagara machines to test with -- with
> PCIe slots they should actually be good for IB testing.
You'll be cpu limited until we have Van Jacobson net channels.
Also, since our existing
* Peter Horton <[EMAIL PROTECTED]> [2006-02-18 22:08]:
> This patch works around the MWI bug on the DC21143 rev 65 Tulip by
> ensuring that the receive buffers don't end on a cache line boundary (as
> documented in the errata).
>
> This patch is required for the MIPs based Cobalt Qube/RaQ as suppo
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 14:01:11 -0800
> This patch introduces the use of rcu for the ipv4 established
> connections hashtable, as well as the timewait table since they are
> closely intertwined.
Thanks for doing this work, I'll try study it seriously very
David> I wrote a test program and it looks ok:
Cool, thanks.
I should look into getting some niagara machines to test with -- with
PCIe slots they should actually be good for IB testing.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EM
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 13:59:39 -0800
> Here's an updated copy of the patch to use fget_light in net/socket.c.
I like this patch a lot, applied to net-2.6.17
I fixed this up by hand:
Adds trailing whitespace.
diff:286: fput_light(sock_file, fput
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 6 Mar 2006 14:24:35 -0800
> The functions list_del followed by list_add_tail is equivalent to the
> existing inline list_move_tail. list_move_tail avoids unnecessary
> _LIST_POISON.
> Trivial for 2.6.17.
>
> Signed-off-by: Stephen Hemminger
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Tue, 7 Mar 2006 00:34:38 +0200
> So I'm trying to get a handle on it: could a solution be to simply
> look at the frame size, and call tcp_send_delayed_ack from
> if the frame size is no larger than 1/8?
>
> Does this make sense?
The comment y
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 14:32:28 -0800
> The fundamental question seems to be whether things like
>
> struct foo {
> struct sockaddr_in6 src;
> struct sockaddr_in6 dst;
> };
>
> and
>
> struct bar {
>
Hello, Dave!
As you might know, the TSO patches merged into mainline kernel
since 2.6.11 have hurt performance for the simple (non-TSO)
high-speed netdevice that is IPoIB driver.
This was discussed at length here
http://openib.org/pipermail/openib-general/2005-October/012271.html
I'm trying to fi
David> Please make sure you check "x86_64 vs. x86", and then
David> something like "powerpc64 vs. powerpc32" or "sparc64
David> vs. sparc32", as those are the two different classes of ABI
David> layouts.
Yes, I tried ppc64 vs ppc and it still comes out the same.
Unfortunately I don
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:58:32 -0800
> Sean> Unless I miss counted, they should be aligned.
> Sean> ib_user_path_rec is defined near the end of patch 1/6.
>
> You're right. struct sockaddr_in6 is 28 bytes long (not a multiple of
> 8) but gcc seems
The functions list_del followed by list_add_tail is equivalent to the
existing inline list_move_tail. list_move_tail avoids unnecessary _LIST_POISON.
Trivial for 2.6.17.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- linux-2.6.orig/net/core/dev.c 2006-03-03 10:33:59.0 -0
Jouni Malinen wrote :
>
> On Mon, Mar 06, 2006 at 04:44:27PM +0100, Jiri Benc wrote:
>
> > PRISM2_PARAM_ADM_STATUS is not used anywhere in kernel nor in userspace.
> > It just passes a value to the driver, so it's safe to remove it.
>
> This is used to implement radio on/off without having to ch
On Mon, 06 Mar 2006 16:57:11 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Mon, 6 Mar 2006 22:30:59 +0100
> > Francois Romieu <[EMAIL PROTECTED]> wrote:
> >
> >
> >>(s/osld.org/osdl.org/g)
> >>
> >>Stephen Hemminger <[EMAIL PROTECTED]> :
> >>
> >>>Redo the interu
Benjamin LaHaise wrote:
Hello folks,
Here's an updated copy of the patch to use fget_light in net/socket.c.
Rerunning the tests show a drop of ~80Mbit/s on average, which looks
bad until you see the drop in cpu usage from ~89% to ~82%. That will
get fixed in another patch...
Before: max 8
Hello again,
This patch introduces the use of rcu for the ipv4 established connections
hashtable, as well as the timewait table since they are closely intertwined.
This removes 4 atomic operations per packet from the tcp_v4_rcv codepath,
which helps quite a bit when the other performance barri
Jens Osterkamp <[EMAIL PROTECTED]> wrote:
>
>
> Which kernel version was this in ? 2.6.16-rc5 builds ok for me.
>
> drivers/net/spider_net.c:421: multiple definition of `mii_phy_probe'
> drivers/net/sungem_phy.o(.opd+0x160):drivers/net/sungem_phy.c:95: first
> defined here -
It was 2.6.16-rc5-m
Hello folks,
Here's an updated copy of the patch to use fget_light in net/socket.c.
Rerunning the tests show a drop of ~80Mbit/s on average, which looks
bad until you see the drop in cpu usage from ~89% to ~82%. That will
get fixed in another patch...
Before: max 8113.70, min 8026.32, avg 80
Sean Hefty wrote:
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] & mask[i];
+}
+
+static int cm_compare_data(struct ib_cm_private_data_compare *src_data,
+
Stephen Hemminger wrote:
On Mon, 6 Mar 2006 22:30:59 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
(s/osld.org/osdl.org/g)
Stephen Hemminger <[EMAIL PROTECTED]> :
Redo the interupt handling of sky2 driver based on the IRQ mangement
documentation. All interrupts are handled by the device0
On Mon, 6 Mar 2006 22:30:59 +0100
Francois Romieu <[EMAIL PROTECTED]> wrote:
> (s/osld.org/osdl.org/g)
>
> Stephen Hemminger <[EMAIL PROTECTED]> :
> > Redo the interupt handling of sky2 driver based on the IRQ mangement
> > documentation. All interrupts are handled by the device0 NAPI poll
> > ro
Sean> Unless I miss counted, they should be aligned.
Sean> ib_user_path_rec is defined near the end of patch 1/6.
You're right. struct sockaddr_in6 is 28 bytes long (not a multiple of
8) but gcc seems to lay everything out the same on 32-bit and 64-bit
architectures just the same.
- R.
Roland Dreier wrote:
> +struct rdma_ucm_query_route_resp {
> + __u64 node_guid;
> + struct ib_user_path_rec ib_route[2];
> + struct sockaddr_in6 src_addr;
> + struct sockaddr_in6 dst_addr;
> + __u32 num_paths;
> + __u8 port_num;
> + __u8 reserved[3];
> +};
Is there a 32-bit/64-bit compa
Roland Dreier wrote:
On the other hand I think it would be good to let this userspace
interface cook a little more, say in -mm.
I think that this makes sense.
- Sean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 06 Mar 2006 13:31:05 -0800
> Sean> Export ip_dev_find to allow locating a net_device given an
> Sean> IP address.
>
> My plan is to queue all of this stuff for merging in 2.6.17.
>
> Is there any objection from netdev or openib-general p
I think it makes sense to merge patches 1-5 independently of this
patch. The kernel interface is needed by iSER and NFS/RDMA, and
maintaining compatibility isn't a huge deal, so we can merge it now
(assuming it looks mergable).
On the other hand I think it would be good to let this userspace
inte
> +struct rdma_ucm_query_route_resp {
> +__u64 node_guid;
> +struct ib_user_path_rec ib_route[2];
> +struct sockaddr_in6 src_addr;
> +struct sockaddr_in6 dst_addr;
> +__u32 num_paths;
> +__u8 port_num;
> +__u8 reserved[3];
> +};
Is there a 32-bit/64-bit compati
(s/osld.org/osdl.org/g)
Stephen Hemminger <[EMAIL PROTECTED]> :
> Redo the interupt handling of sky2 driver based on the IRQ mangement
> documentation. All interrupts are handled by the device0 NAPI poll
> routine.
Is there something beyond smarter irq handling which would urge to
merge this code
Sean> Export ip_dev_find to allow locating a net_device given an
Sean> IP address.
My plan is to queue all of this stuff for merging in 2.6.17.
Is there any objection from netdev or openib-general people?
I just looked back, and the original "unexport ip_dev_find()" patch
was a de-Bunk-i
Wrong version... of patch please use this one!
-
The driver includes support for the lowcost version of Yukon-EC chipset.
Since this has never been explictly tested, add a disclaimer message
to get some feedback.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-1.0.orig/drivers/
Which kernel version was this in ? 2.6.16-rc5 builds ok for me.
drivers/net/spider_net.c:421: multiple definition of `mii_phy_probe'
drivers/net/sungem_phy.o(.opd+0x160):drivers/net/sungem_phy.c:95: first
defined here -
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
Martin Michlmayr <[EMAIL PROTECTED]> :
[...]
> There's another interrupt related bug in the driver, though. I
> sometimes get a kernel panic when rsycing several 100 megs of data
> across the LAN. A picture showing the call trace can be found at
> http://www.cyrius.com/tmp/de2104x_panic.jpg
Not
1 - 100 of 182 matches
Mail list logo
