Just be realistic and accept that RDMA is a point in time solution,
and like any other such technology takes flexibility away from users.
All technologies are just point in time solutions. While management is
important, shouldn't the customers decide how important it is relative to their
From: Sean Hefty [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 00:01:07 -0700
Millions of Infiniband ports are in operation today. Over 25% of the top 500
supercomputers use Infiniband. The formation of the OpenFabrics Alliance was
pushed and has been continuously funded by an RDMA customer - the
I noticed that FreeBSD has a useful SOL_SOCKET option, SO_NOSIGPIPE, which
is a sticky version of MSG_NOSIGNAL. Particularly useful for libraries,
it disables SIGPIPE on a particular socket without disabling it globally.
Anyway, this led me to look at the implementation of SIGPIPE and
On Sat, 18 Aug 2007 06:59:08 -0700 (PDT)
Kevin E [EMAIL PROTECTED] wrote:
--- Willy Tarreau [EMAIL PROTECTED] wrote:
OK, in this trace, both controllers are on the same
bus. The broken
one has 'Capabilities: [100] Advanced Error
Reporting' the other
does not have, and the bridge to
--- Stephen Hemminger
[EMAIL PROTECTED] wrote:
The working board has a different version of the
Marvell chip:
$ grep Marvell working-MB
04:00.0 Ethernet controller: Marvell Technology
Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
(rev 14)
$ grep Marvell broken-MB
04:00.0
-Original Message-
From: [EMAIL PROTECTED] [mailto:general-
[EMAIL PROTECTED] On Behalf Of David Miller
Sent: Sunday, August 19, 2007 12:24 AM
To: [EMAIL PROTECTED]
Cc: netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject:
The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
--- Stephen Hemminger
[EMAIL PROTECTED] wrote:
The driver prints some chip version info at startup,
that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
Here's the output from the working MB:
sky2 :04:00.0: v1.14 addr 0xf800 irq 16
Yukon-EC Ultra
From: Felix Marti [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 10:33:31 -0700
I know that you don't agree that TSO has drawbacks, as outlined by
Roland, but its history showing something else: the addition of TSO
took a fair amount of time and network performance was erratic for
multiple kernel
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 12:32 PM
To: Felix Marti
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ofa-general] Re: [PATCH
Felix Marti [EMAIL PROTECTED] writes:
what benefits does the TSO infrastructure give the
non-TSO capable devices?
It improves performance on software queueing devices between guests
and hypervisors. This is a more and more important application these
days. Even when the system running the
On 19-Aug-07, at 2:34 PM, Stephen Hemminger wrote:
The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:
dmesg | grep sky2
sky2 :03:00.0: v1.16 addr 0xfa00 irq 16 Yukon-EC Ultra (0xb4)
rev 2
sky2 eth0: addr
From: Felix Marti [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 12:49:05 -0700
You're not at all addressing the fact that RDMA does solve the
memory BW problem and stateless offload doesn't.
It does, I just didn't retort to your claims because they were
so blatantly wrong.
-
To unsubscribe from
From: Andi Kleen [EMAIL PROTECTED]
Date: 20 Aug 2007 01:27:35 +0200
Felix Marti [EMAIL PROTECTED] writes:
what benefits does the TSO infrastructure give the
non-TSO capable devices?
It improves performance on software queueing devices between guests
and hypervisors. This is a more and
From: John W. Linville [EMAIL PROTECTED]
Date: Tue, 14 Aug 2007 20:34:10 -0400
Johannes Berg (1):
radiotap parser: accept all other fields
Larry Finger (1):
mac80211: Add SIOCGIWTXPOWER routine
I've rebased net-2.6.24 and added in these two wireless
patches, thanks!
-
To
Felix Marti [EMAIL PROTECTED] wrote:
[Felix Marti] Aren't you confusing memory and bus BW here? - RDMA
enables DMA from/to application buffers removing the user-to-kernel/
kernel-to-user memory copy with is a significant overhead at the
rates we're talking about: memory copy at 20Gbps
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 4:04 PM
To: Felix Marti
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ofa-general] Re: [PATCH
From: Felix Marti [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 17:32:39 -0700
[ Why do you put that [Felix Marti] everywhere you say something?
It's annoying and superfluous. The quoting done by your mail client
makes clear who is saying what. ]
Hmmm, interesting... I guess it is impossible to
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 5:40 PM
To: Felix Marti
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ofa-general] Re: [PATCH
From: Felix Marti [EMAIL PROTECTED]
Date: Sun, 19 Aug 2007 17:47:59 -0700
[Felix Marti]
Please stop using this to start your replies, thank you.
David and Herbert, so you agree that the userkernel
space memory copy overhead is a significant overhead and we want to
enable zero-copy in both
Someone wrote me with a solution to try and so far
it's working. They suggested I try the driver up on
Marvell's website but to make sure I powered off the
machine completely and when it rebooted to not have
any of the regular kernel drivers for the Marvell
chipset to load. They had found that
On Sat, Aug 18, 2007 at 11:36:24AM -0500, Kumar Gala wrote:
This patch seems to mix moving to using the device tree directly w/o
some other modifications. Can it be broken into those two changes as
they'd be easier to review.
The last iteration of these patches, I got complaints that I
If ICMP6 message with Packet Too Big is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to skb_copy_bits().
The messages sequence is like this:
Endpoint A Endpoint B
-Original Message-
From: David Miller [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 6:06 PM
To: Felix Marti
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [ofa-general] Re: [PATCH
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
Sent: Sunday, August 19, 2007 4:28 PM
To: Felix Marti
Cc: David Miller; [EMAIL PROTECTED]; netdev@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re:
Em Mon, Aug 20, 2007 at 09:28:27AM +0800, Wei Yongjun escreveu:
If ICMP6 message with Packet Too Big is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to skb_copy_bits().
The messages sequence is like
In article [EMAIL PROTECTED] (at Mon, 20 Aug 2007 09:28:27 +0800), Wei
Yongjun [EMAIL PROTECTED] says:
If ICMP6 message with Packet Too Big is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to
Hi Arnaldo Carvalho de Melo:
Em Mon, Aug 20, 2007 at 09:28:27AM +0800, Wei Yongjun escreveu:
If ICMP6 message with Packet Too Big is received after send SCTP DATA,
kernel panic will occur when SCTP DATA is send again.
This is because of a bad dest address when call to skb_copy_bits().
The
28 matches
Mail list logo
