Loic Prylli wrote:
On 4/30/2007 2:12 PM, Rick Jones wrote:
Speaking of defaults, it would seem that the external 1.2.0 driver
comes with 9000 bytes as the default MTU? At least I think that is
what I am seeing now that I've started looking more closely.
rick jones
That's the same
What version of the myri10ge driver is this? With the 1.2.0 version
that comes with the 2.6.20.7 kernel, there is no myri10ge_lro module
parameter.
[EMAIL PROTECTED] ~]# modinfo myri10ge | grep -i lro
[EMAIL PROTECTED] ~]#
And I've been testing IP forwarding using two Myricom 10-GigE NICs
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:48:00 -0700
No problem - just to play whatif/devil's advocate for a bit
though... is there any way to tie that in with the setting of
net.ipv4.ip_forward (and/or its IPv6 counterpart)?
Even ignoring
.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
receive offload enabled. That may need some discussion in netdev - it may
then require some changes to default settings or some documentation
enhancements. That or I'll learn that the stack is already dealing with the
issue...
rick jones
bryan
At 11:06 AM 4/26/2007, Michael S. Tsirkin
an ethtool command, for some suitable revision of ethtool.
rick jones
Thanks for listening and re enforcing my search process.
bryan
At 01:32 PM 4/27/2007, Rick Jones wrote:
Bryan Lawver wrote:
Your right about the ipoib module not combining packets (I believed
you without checking) but I did
checksum offloading via ethtool:
# ethtool -K eth2 rx off
/excerpt
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:37:49 -0700
Large Receive Offload (LRO) is enabled by default. This will
interfere with forwarding TCP traffic. If you plan to forward TCP
traffic (using the host with the Myri10GE NIC as a router or bridge
that is flushed through TCP only between tests
(and thus does not cause timing problems).
Might tcp_abc have crept back-in?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
.
Either that timer didn't get set, didn't fire, or was insufficient to
get netserver out of that recv() on the UDP socket, or comms between the
two system got fubar for TCP too.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By : Jesse Brandeburg [EMAIL
I booted up 2.6.21rc7 without an ethernet cable plugged in,
and noticed this..
e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of :02:00.0 failed with error -5
I plugged a cable in, did rmmod e1000;modprobe e1000, and got this..
e1000: :02:00.0:
On Wed, Apr 04, 2007 at 06:10:42PM -0700, Arjan van de Ven wrote:
On Thu, 2007-04-05 at 10:44 +1000, Herbert Xu wrote:
Stephen Hemminger [EMAIL PROTECTED] wrote:
Thanks Dave, there is a classic AB BA deadlock here.
We should break the dependency like this.
Could someone who
of
a Mbit/s.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
===
[ INFO: possible circular locking dependency detected ]
2.6.20-1.2933.fc6debug #1
---
swapper/0 is trying to acquire lock:
(tbl-lock){-+-+}, at: [c05d5664] neigh_lookup+0x43/0xa2
but task
teach ethtool to print 1Mb/s for a 10G NIC and prepare
for 10G NICs where it is possible to run something other than 10G
update the ethtool.8 manpage with info re same and some grammar fixes
Signed-off-by: Rick Jones [EMAIL PROTECTED]
the likely required asbestos at the ready :)
rick jones
/parity throughout their _entire_ data path?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
on their heartbeats.
If the switchover from active to standby is uncommanded it probably
means the primary went belly-up which means you don't have the
opportunity to make an ioctl call anyway, and you are back to the
heartbeats.
rick jones
-
To unsubscribe from this list: send the line
demand, or better yet, disable the interrupt coalescing.
Otherwise, measuring peak aggregate request/response becomes necessary.
rick jones
don't be blinded by bit-rate
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
, and a [EMAIL PROTECTED] if one
wants to discuss actual netperf (netperf2 or netperf4) development.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I have some 10gig nics and ethtool is reporting unknown for the speed.
Is there already a patch, or have I found an opportunity? FWIW, the
version five bits from sourceforge still report unknown - are they the
latest or are there later bits somewhere?
thanks,
rick jones
-
To unsubscribe from
that such a mechanism exists in HP-UX 11.X and I suspect
Solaris !-( I've spent probably the last decade or so attempting to
discourage its use in the HP-UX space, but like some daemon from hell it
just refuses to die.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
Turning up the warnings on gcc makes it emit warnings
about the placement of 'inline' in function declarations.
Here's everything that was under net/
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 4c914df..ecfe8da 100644
as hex values)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
from TIME_WAIT to ESTABLISHED might be greater,
but going back to the good old days of more or less purly clock driven
ISN's isn't likely.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
pending
connection is allowed at any given time.
/excerpt
I don't have a Solaris, BSD or AIX manpage for listen handy to check
them but would not be surprised to see they are similar.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
space, less the previous connection's window (IIRC).
rick jones
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
cannot assume that a packet destined for a given IP address will
remain detined for that given IP address as it could go through a module
that will rewrite headers etc.
Is traffic destined for 127.0.0.1 immune from that?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
. If the delay
there starts to match the delay as you go out to the right on the graph
it would suggest that it is indeed cache effects.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
anyone observed similar behaviour?
Any inputs or suggestions are welcome.
In each case is the malta CPU bound? If not, some idea of the change in
CPU util might be helpful.
rick jones
btw, netperf 2.4.3 just released:
ftp://ftp.netperf.org/netperf
http://www.netperf.org/svn/netperf2/tags
On Thu, Feb 15, 2007 at 02:45:07AM -0800, Andrew Morton wrote:
I've recently been noticing nasty messages come out of FC5:
sony:/home/akpm# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter
last data segment with
the FIN because cwnd wasn't large enough at the time, should the FIN be
sent at that point, even if it is waffer thin?
rick jones
2 cents tossed-in from the peanut gallery
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
are
doing much better than I currently do, particularly from an
architecture perspective - I think that it may involve all the
prequeue/try to get the TCP processing on the user's stack stuff but I'm
_far_ from certain.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
Andi Kleen wrote:
Rick Jones [EMAIL PROTECTED] writes:
Still, does this look like something worth persuing? In a past
life/OS when one was able to eliminate one percentage point of
spinlock contention, two percentage points of improvement ensued.
The stack is really designed to go fast
, lock_sock_nested at their
same offsets.
However, if I run the multiple-connection-per-thread code, and have each
service 32 concurrent connections, and bind to a CPU other than the
interrupt CPU, the lock contention in this case does appear to go away.
rick jones
-
To unsubscribe from this list: send
Yes the wakeup happens deep inside the critical section and if the process
is running on another CPU it could race to the lock.
Hmm, i suppose the wakeup could be moved out, but it would need some
restructuring of the code. Also to be safe the code would still need
to at least hold a reference
to eliminate one percentage point of spinlock
contention, two percentage points of improvement ensued.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rick Jones wrote:
A 2.6.10-rc5 kernel onto each system thanks to pointers from Dan Frazier.
gaak - 2.6.20-rc5 that is.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
that the port assignments are not changed.
(fwiw this is one of two reasons i've found for libnss-ldap to leak
sockets... causing nscd to crash.)
Of course, that seems rather odd too - why does libnss-ldap check the
socket name on a socket after an EPIPE anyway?
rick jones
-
To unsubscribe from
. (Not that
some irqbalancer programs recognize that just yet :)
Now, if both CPU0 and CPU1 are saturated it might make sense to put some
interrupts on 2 and/or 3. One of those fun it depends situations.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
. No issues about reordering, but
perhaps some on cache lines going hither and yon.
The question boils down to - Should the application (via the scheduler)
dictate where its connections are processed, or should the connections
dictate where the application runs?
rick jones
-
To unsubscribe
for load, not the number of interrupts. (for network
interrupts obviously)
And hopefully some knowledge of NUMA so it doesn't balance the
interrupts of a NIC to some far-off (topology-wise) CPU...
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
packets queued
What implications does c have for something like tcpdump?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
allocation retries succeed.
While tossing a TCP|UDP|SCTP|etc packet could be plusungood, especially
if the IOMMU fills frequently (for some suitable definiton of
frequently), is it really worth the effort to save say an ACK?
rick jones
-
To unsubscribe from this list: send the line unsubscribe
of 10 KByte/s connections
you could support. It would be a bit of handwaving, but give yourself
say a 20% pad and you'll probably be OK.
rick jones
Kind Regards
James
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
?) to show a perfomance effect with netperf and it didn't do
it :(
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 18, 2006 at 04:40:00PM +0200, Michael Buesch wrote:
On Wednesday 18 October 2006 01:12, Daniel Drake wrote:
Larry Finger pointed out a problem with my ieee80211 IV/ICV stripping
patch,
which I forgot about. Sorry about that.
The patch readds the frame_ctl assignment
On Fri, Oct 20, 2006 at 01:25:32PM -0700, Stephen Hemminger wrote:
On Fri, 20 Oct 2006 12:52:26 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 20 Oct 2006 12:25:27 -0700
Sorry, but why should we treat out-of-tree vendor
Kumar Gala wrote:
I was wondering if anyone has had any issues when trying to force a
BCM5461 phy into 10M/full duplex. I seem to be having an issue in the
two managed switches I've tried this on but autoneg to 10/half. This
causes a problem in that I start seeing a large number of frame
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
index db23249..1eae16b 100644
--- a/drivers/net/sb1250-mac.c
+++ b/drivers/net/sb1250-mac.c
@@ -2903,7 +2903,7 @@ #endif
dev = alloc_etherdev(sizeof(struct sbmac_softc
Eric Dumazet wrote:
Rick Jones a écrit :
More to the point, on what basis would the application be rejecting a
connection request based solely on the SYN?
True, it isn't like there would suddenly be any call user data as in
XTI/TLI.
DATA payload could be included in the SYN packet. TCP
IPPROTO_SCTP in the hints.
thanks,
rick jones
http://www.netperf.org/svn/netperf2/trunk/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
are
validated. I may have some of the timing a bit wrong though.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
sfuzz.c (google for it if you don't have it already) used to
run forver (or until I got bored and ctrl-c'd it) as long
as it didn't trigger an oops or the like in 2.6.17
Running it against 2.6.18, I notice that it runs for a while,
and then gets totally wedged. It doesn't respond to any signals,
the connect request of the
client. If not, it should be possible to reject the connect request.
How often do you expect the incomming call to be rejected? I suspect that would
have a significant effect on whether the whole thing is worthwhile.
rick jones
-
To unsubscribe from this list: send the line
the application to
set socket buffer sizes rather than relying on the system's default.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2) develop some style
of register description definition type of text file, maybe XML, maybe
INI style or something stored in /etc/ethtool as drivername.conf or
something like that. This way, ethtool doesn't have to be
changed/updated/patched/likely-bug-added for every single device known
to
will eventually stop
responding after a while.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
With mii-tool we can do the command below and work with a half duplex
hub and a full duplex switch.
mii-tool -A 10baseT-FD,10baseT-HD eth0
Why, and how often, is that really necessary?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Auke Kok wrote:
Rick Jones wrote:
With mii-tool we can do the command below and work with a half duplex
hub and a full duplex switch.
mii-tool -A 10baseT-FD,10baseT-HD eth0
Why, and how often, is that really necessary?
This is a bit of a hypothetical discussion of course, but I can
On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote:
Patrick McHardy wrote:
jamal wrote:
Yes, that looks plausible. Can you try making those changes and see if
the warning is gone?
I think this points to a bigger brokeness caused by the move of
dev-qdisc to
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-R} - {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[2]:HE1:SE0] takes:
(police_lock){-+--}, at: [f8d304fd] tcf_police_destroy+0x24/0x8f [act_police]
{softirq-on-R} state
Alexey Kuznetsov wrote:
Hello!
transactions to data segments is fubar. That issue is also why I wonder
about the setting of tcp_abc.
Yes, switching ABC on/off has visible impact on amount of segments.
When ABC is off, amount of segments is almost the same as number of
transactions. When
extensions and gets some
additional parallelism in the stack on SMP systems.
Why it needs/wants the timestamps I've no idea, I don't think it gets
them that way on all platforms. I suppose the next time I do some named
benchmarking I can try to take a closer look in the source.
rick jones
they may be to reorder traffic.
Is this same for all kernel (linux/solaris)?
Your application should be written on the assumtion that it is possible,
regardless of the specifics of the OSes involved, however unlikely they
may be to reorder traffic.
rick jones
-
To unsubscribe from this list
it was not in
promiscuous mode - the delta being (perhaps) multicast frames.
rick jones
(*) Today, it seems 99 times out of 10 systems are connected to
switches not hubs.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
. Destination
stack is a distant second and source stack an even more distant third.
Generally stack writers try to avoid having places in their stacks where
things can reorder, but it isn't completely unknown.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
Refine cb cleaning debug printout and print out all cleaned cbs' status. Add
debug flag for EEPROM csum failures that were overridden by the user.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok
On Tue, Sep 19, 2006 at 05:40:34PM -0400, Jeff Garzik wrote:
Dave Jones wrote:
On Tue, Sep 19, 2006 at 10:28:38AM -0700, Kok, Auke wrote:
+ add_taint(TAINT_MACHINE_CHECK);
I object to this flag being abused this way.
A corrupt EEPROM on a network card has
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 05 Sep 2006 10:55:16 -0700
Is this really necessary? I thought that the problems with ABC were in
trying to apply byte-based heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
This is receiver side
the concern about
increases in service demand.
But actually, it is not about increasing/decreasing number of ACKs.
It is about killing that pain in ass which we used to have because
we pretended to be too smart.
:)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
of most people and netdev aren't completely
overlapping.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
wont to do) missed something quasi-obvious?
thanks,
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
heuristics from the RFC(s) to a
packet-oritented cwnd in the stack?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Seen during boot of a 2.6.18rc5-git1 based kernel.
Dave
===
[ INFO: possible circular locking dependency detected ]
2.6.17-1.2608.fc6 #1
---
swapper/0 is trying to acquire
of a byte-based RFC to packet-counting cwnd?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
? (-v 2 on the netperf
command line should show what the MSS was for the connection)
rick jones
BTW, many points scored for including CPU utilization and service demand
figures with the netperf output :)
[All tests run with maxcpus=1 on a 2.67GHz Woodcrest system.]
Recv SendSend
feature should be supported from kernel versions 2.6.16 onwards.
I would think that if run on an end system at least, trying to corrupt
packets with CKO enabled on a NIC might be, well, difficult. Or does
netem disable CKO?
rick jones
-
To unsubscribe from this list: send the line unsubscribe
high DMA setup latency, and then if you put it into a system
with highish DMA read/write latency... well that didn't make it any
better :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
On Tue, Aug 15, 2006 at 03:25:58PM -0400, Pavel Roskin wrote:
diff --git a/drivers/net/wireless/orinoco.h b/drivers/net/wireless/orinoco.h
index 16db3e1..8fd9b32 100644
--- a/drivers/net/wireless/orinoco.h
+++ b/drivers/net/wireless/orinoco.h
@@ -135,11 +135,9 @@ extern irqreturn_t
On Wed, Aug 09, 2006 at 09:04:38PM -0700, David Miller wrote:
From: Dave Jones [EMAIL PROTECTED]
Date: Wed, 9 Aug 2006 22:21:16 -0400
config.h is automatically included by kbuild these days.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
Applied to net-2.6.19, thanks Dave
We've just added an implicit declaration in the latest tree..
net/ipx/af_ipx.c: In function 'ipx_rcv':
net/ipx/af_ipx.c:1648: error: implicit declaration of function 'ipxhdr'
(Yes, my builds fail on -Werror-implicit, so that things like this get caught
early)
Probably something simple like a
config.h is automatically included by kbuild these days.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
--- linux-2.6/net/ipv4/netfilter/ip_conntrack_sip.c~2006-08-09
22:18:48.0 -0400
+++ linux-2.6/net/ipv4/netfilter/ip_conntrack_sip.c 2006-08-09
22:18:53.0 -0400
@@ -8,7
From a recent rc3-git kernel.
Dave
--
http://www.codemonkey.org.uk
---BeginMessage---
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201560
jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
Could we please just get rid of the wireless extensions over netlink code
again? It doesn't help to solve anything and just creates a bigger mess
to untangle when switching to a fully fledged wireless stack.
If we're going
On Thu, Aug 03, 2006 at 11:58:00AM -0700, Jean Tourrilhes wrote:
On Thu, Aug 03, 2006 at 03:11:53PM +0100, Christoph Hellwig wrote:
On Thu, Aug 03, 2006 at 11:54:41PM +1000, Herbert Xu wrote:
Arjan van de Ven [EMAIL PROTECTED] wrote:
this is another one of those nasty buggers;
Wow. Nearly 400 lines of debug spew, from a simple 'ifup eth1'.
Dave
ADDRCONF(NETDEV_UP): eth1: link is not ready
eth1: New link status: Disconnected (0002)
==
[ INFO: hard-safe - hard-unsafe lock order detected ]
traffic _only_ when
both sides of the link try to speak at the same time. A typical ping
test, being synchronous, one at a time request/response, never tries
to have both sides talking at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.
rick jones
2.6.18rc2-gitSomething on my firewall box just triggered this..
Dave
[515613.791771] ===
[515613.841467] [ INFO: possible circular locking dependency detected ]
[515613.873284]
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 24 Jul 2006 17:55:24 -0700
Even enough bits for 1024 or 2048 CPUs in the single system image? I have seen
1024 touted by SGI, and with things going so multi-core, perhaps 16384 while
sounding initially bizzare would
That TOE/iWARP could end-up being precluded by NAT seems so ironic from a POE2E
standpoint.
rick jones
Purity Of End To END
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
though mean that the state is per-packet
without it having to be based on addressing information. Almost like RDMA
arriving saying where the data goes, but this thing says where the processing
should happen :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 24 Jul 2006 17:29:05 -0700
Nirvana I suppose would be the addition of a field in the header
which could be used for the determination of where to process. A
Transport Protocol option I suppose, maybe the IPv6 flow id, but
knuth
?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
mainline, and backed out numerous fixes
made to it in the mainline kernel. It's a huge effort to get the 'good bits'
out of that patch, and letting it die is the only sensible solution IMO.
ACKed-by: Dave Jones [EMAIL PROTECTED]
+SK98LIN GIGABBIT ETHERNET DRIVER
typo :-)
Dave
been touched by the cpu in some time and are thus nearly
guarenteed to be cold in the cache.
This is the kind of work we could think about batching to user
sleeping on some socket call.
Ultimately isn't that just trying to squeeze the balloon?
rick jones
nice to see people seeing ACKs
net/sched/sch_htb.c: In function 'htb_change_class':
net/sched/sch_htb.c:1605: error: expected ';' before 'do_gettimeofday'
Signed-off-by: Dave Jones [EMAIL PROTECTED]
--- linux-2.6.17.noarch/net/sched/sch_htb.c~2006-07-15 03:40:14.0
-0400
+++ linux-2.6.17.noarch/net/sched/sch_htb.c
the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I suspect the URL above there will start one on the path to the email
archive.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
401 - 500 of 666 matches
Mail list logo
