register clears per second (slow
ioread/writes). The transactions double for TCP ack processing, and this all
accumulates and starts to introduce latency, higher cpu utilization etc...
Sounds like tools to show PCI* bus utilization would be helpful...
rick jones
--
To unsubscribe from this list: send
Andi Kleen wrote:
On Thu, Jan 31, 2008 at 10:26:19AM -0800, Rick Jones wrote:
Andi Kleen wrote:
TSO interacts badly with many queueing disciplines because they rely on
reordering packets from different streams and the large TSO packets can
make this difficult. This patch disables TSO
matter of getting specs for the various LBA's (is that the correct
term? - lower bus adaptors) and then abstracting them a la the CPU perf
counters as done by say perfmon and then used by papi :)
rick jones
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body
(and perhaps input as to how much time any one burst of
data should be allowed to consume on the network) and pass that up the
stack? right now you seem to be proposing what is effectively a cap of
1 MSS.
rick jones
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body
lets the kernel auto-tune.
That is the bit where explicit setsockopts are capped by core [rw]mem
sysctls but the autotuning is not correct?
rick jones
BTW, a bit of netperf news - the omni (two routines to measure it all)
tests seem to be more or less working now in top of trunk netperf
over loopback, but probably needs to be a check for any local IP,
and unless this becomes something bigger than Doctor! Doctor! It hurts
when I do this! :) I'm inclined to leave it as caveat benchmarker and
perhaps some additional text in the manual.
rick jones
--
To unsubscribe from this list
benchmarking,
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
it.
*) The -i option to set the confidence iteration count will silently cap
the max at 30.
happy benchmarking,
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
you describe the I/O subsystem more completely? I understand that
you are using at most two ports of a pair of quad-port cards at any one
time, but am still curious to know if those two cards are on separate
busses, or if they share any bus/link on the way to memory.
rick jones
the global -T option to spread the netperf/netserver
processes across the CPUs, or leaving that all up to the
stack/scheduler/etc?
I suspect there could be more but that is what comes to mind thusfar as
far as things I often check when running netperf.
rick jones
--
To unsubscribe from this list
: 00 0 1234 eth3
which you should be able to acheive via the method I think someone else
has already mentioned about echoing values into
/proc/irq/irq/smp_affinity - after you have slain the dreaded
irqbalance daemon.
rick jones
--
To unsubscribe from this list
processed on both CPUs at
various points in the past, it doesn't necessarily mean that they are
being processed on both CPUs at the same time right?
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
length with a normal read/recv, and then read that many
bytes in the next call?
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, Dec 12, 2007 at 05:53:43PM +0100, Thomas Klein wrote:
+static void ehea_update_adapter_handles(struct ehea_adapter *adapter)
+{
+int i, k;
+int j = 0;
+
+memset(adapter-res_handles, sizeof(adapter-res_handles), 0);
arguments wrong way around.
Dave
--
the
alloc_tbufs(), but I feel if a real interrupt occured, this diff would
stand more chance of doing the right thing.
Comments?
Dave
Delay irq registration until after we've allocated ring buffers,
otherwise DEBUG_SHIRQ will complain.
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git
at the same time.
Finally, when/if you migrate to 1000Base-T, everything has to be set
to auto-neg anyway.
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
Could the corruption be seen in a tcpdump trace prior to transmission
(ie taken on the sender) or was it only seen after the data passed out
the NIC?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
1) Why is everyone so concerned that export symbol space is large?
- does it cost cpu or running memory?
- does it cause bugs?
- or are you just worried about evil modules?
To clarify something here, by
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of TOE comes to mind right away.
rick jones
-
To unsubscribe from this list: send
On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
1) Why is everyone so concerned that export symbol space is large?
- does it cost
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling
On Thu, Nov 22, 2007 at 03:43:06AM +0100, Andi Kleen wrote:
There seems to be rough consensus that the kernel currently has too many
exported symbols. A lot of these exports are generally usable utility
functions or important driver interfaces; but another large part are
functions
back I thought I saw that LRO on the
receiver was causing him to send fewer ACKs already? IIRC that was with
a Myricom card, perhaps I was fooled by it's own ACK LRO it was doing.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
, but if someone were looking at that and saw the
value large they might make an educated guess.
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
MAC address from?
Not part of your change, but since you are editing the section, drop the
from in the section title, or perhaps put it at the beginning so we
don't have a dangling whatchamacallit.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
Jay -
So, where do you and I stand wrt the proposed changes to bonding.txt? Are we at
an impass?
sincerely,
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
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Past performance is no guarantee of current correctness :) And over an
Ethernet, there will be a very different set of both timings and TCP
segment sizes compared to loopback.
My guess is that you will find setting the lo
Jay Vosburgh wrote:
Rick Jones [EMAIL PROTECTED] wrote:
So, where do you and I stand wrt the proposed changes to bonding.txt? Are
we at an impass?
Nope, I'm doing a doc update next to incorporate several things,
the reordering stuff included (which I plan to change to describe
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
How could I test this theory?
Can you take another trace that isn't so cooked? One that just sticks
with TCP-level and below stuff?
Sorry for taking so long. Here is a tcpdump. The side on port 445 is
the SMB server
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Oh I'm pretty sure it's not my application, because my application performs
well over ethernet, which is after all its purpose. Also I see the
write, the TCP uncork, then a pause, and then the packet leaving.
Well, a wise
finding a 64 core system with a suitable workload to try
this could be a good thing. Wish I had one at my disposal.
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
we got that patched to use the length of zero as a ah,
this was TSO so wing it heuristic.)
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: Thu, 01 Nov 2007 14:48:45 -0700
One could I suppose try to ammend the information passed to allow
tcpdump to say oh, this was a tx packet on the same machine on
which I am tracing so don't worry about checksum mismatch
We do
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
I'll try to go pester folks in tcpdump-workers then.
The thing to check is TP_STATUS_CSUMNOTREADY.
When using mmap(), it will be provided in the descriptor. When using
recvmsg() it will be provided via a PACKET_AUXDATA control message
Jones [EMAIL PROTECTED]
---
diff -r 35e54d4beaad Documentation/networking/bonding.txt
--- a/Documentation/networking/bonding.txt Wed Oct 24 05:06:40 2007 +
+++ b/Documentation/networking/bonding.txt Mon Oct 29 03:47:19 2007 -0700
@@ -1696,23 +1696,6 @@ balance-rr: This mode
Jay Vosburgh wrote:
Rick Jones [EMAIL PROTECTED] wrote:
[...]
- Note that this out of order delivery occurs when both the
- sending and receiving systems are utilizing a multiple
- interface bond. Consider a configuration in which a
- balance-rr bond feeds
right now...)
Let me know if this works for you or not.
I don't know if it worked for Stephen, but it certainly worked to get rid of the
last three rename-induced stack traces on my system.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
Jay Vosburgh wrote:
Rick Jones [EMAIL PROTECTED] wrote:
I have to wonder if the full description of the different versions of
being a little bit pregnant is worth it. Just saying that using
balance-rr will result in reordering seems much more simple to comprehend.
True
effect on the
congestion window, limiting the number of outstanding segments.
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
it appears as eth6.
rick jones
...
Jeff
-
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
-
To unsubscribe from this list: send the line unsubscribe netdev
or the receiver rather than the
sender would be a good thing, and trying again with CKO disabled on the
interface(s) (via ethtool) might be something worth looking at. Ultimately,
doing the partial checksum modificiations in a CKO-friendly manner might be a
good thing.
rick jones
-
To unsubscribe from
SubmittingPatches)
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
-by: Rick Jones [EMAIL PROTECTED]
---
diff -r 35e54d4beaad drivers/net/fealnx.c
--- a/drivers/net/fealnx.c Wed Oct 24 05:06:40 2007 +
+++ b/drivers/net/fealnx.c Fri Oct 26 06:12:00 2007 -0700
@@ -866,7 +866,7 @@ static int netdev_open(struct net_device
// np-bcrvalue=0x04 | 0x0x38
to
prefer the attached patch...
That achieves my desired end result of no warning while compiling on ia64 so I'm
happy with it. I suspect that may also get rid of a warning on parisc so I
should be doubly pleased :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev
.
Although it does rather sound like a driver writer yanking the rope from the
hand's of the sysadmin and hanging him with it rather than letting the sysadmin
do it himself. I've seen other drivers' README's suggesting larger mem's but
not their sources doing it.
rick jones
-
To unsubscribe from
and is at the mercy of sysctls. I wonder if it would be
better to have it use their FORCE versions to make life easier on the
benchmarker - such as myself - who has an unfortunate habit of forgetting to
update sysctl.conf :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe
things when multiple
interfaces are connected to the same broadcast domain.
That the all interfaces have one MAC default behaviour on SPARC systems often
ran into troubles is probably cautionary here.
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
In any case, this patch should not be merged. We often send it around to
users to
debug their issue in case it involves eeproms, but merging it will just
conceal
the real issue and all of a sudden a flood of people stop
On Tue, Oct 23, 2007 at 04:03:38PM -0700, Kok, Auke wrote:
Dave Jones wrote:
On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
In any case, this patch should not be merged. We often send it around
to users to
debug their issue in case it involves eeproms
windows which might be an interesting experiment.
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 Thu, Oct 18, 2007 at 10:59:59AM -0700, Kok, Auke wrote:
David Mack wrote:
It appears that the needed e100 fix made it into the Fedora
2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now
setting the
lowlatency sysctl - both processes being on the same CPU might interact poorly
with the attempts to run things on the receiver's stack.
rick jones
I guess I've not managed to lose the race to a packet trace... :)
-
To unsubscribe from this list: send the line unsubscribe netdev
unpunished suggests that Matthew and I are now in a race to
take some tcpdump traces :)
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
switch the output of a TCP_RR test to bits or bytes per second a la the
_STREAM tests.
rick jones
My initial idea was that it has something todo with the different MTU on
loopback. My initial block size was 16k, but the problem stayed when I
changed it to 64k.
Felix
-
To unsubscribe from
the packet trace was a bit too cooked perhaps, but there were indications that
at times the TCP window was going to zero - perhaps something with window
updates or persist timers?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Failover between disparate link-types sounds like a job for IP and routing.
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
listening TCP sockets, and next list all established
TCP connections. A typical entry of /proc/net/tcp would look like this (split
/proc/net/[tcp|tcp6] are deprecated now right? Perhaps there should be
something to that effect added to the txt.
rick jones
-
To unsubscribe from this list
On Thu, Oct 11, 2007 at 09:10:34AM -0700, Kok, Auke wrote:
Herbert Xu wrote:
On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
The e1000 changes you reference above, is this the changeset you mean?
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok [EMAIL
broken hardware fixed it
might let him limp along until then.
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 Thu, Sep 27, 2007 at 02:58:27PM +0800, Herbert Xu wrote:
Kok, Auke [EMAIL PROTECTED] wrote:
Dave Jones wrote:
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same
.23-rc8 based
Reported by a Fedora user this morning.
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0: Adding slave eth0.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
bonding: bond0:
with the network. I doubt that SO_BUF settings would
change that, but perhaps setting watermarks might (wild ass guess). The
watermarks will do nothing on HP-UX though (IIRC).
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
has anyone already asked whether link-layer flow-control is enabled?
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
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
While I am often
transfers. (That they both have them stems from
their being cousins, sharing a common TCP stack ancestor long ago - both of
course have been diverging since then).
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
-v3.27
bus-info: :01:02.0
rick jones
net.ipv6.conf.eth2.router_probe_interval = 60
net.ipv6.conf.eth2.accept_ra_rtr_pref = 1
net.ipv6.conf.eth2.accept_ra_pinfo = 1
net.ipv6.conf.eth2.accept_ra_defrtr = 1
net.ipv6.conf.eth2.max_addresses = 16
net.ipv6.conf.eth2.max_desync_factor = 600
net.ipv6
with a
ProCurve on my rx2660's.
I can also run bw_tcp from lmbench 3.0a8 and get 106 MB/s.
I don't have a netgear switch to try in all this...
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
Send Recv (avg) Send (avg)
8 8 0 0 1.181e+09 1452.38812953 16384.00 72065
Maximum
Segment
Size (bytes)
1448
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
disable checksum offload with ethtool.
Or take the packet traces outboard of the NIC somewhere/somehow.
What problem(s) led to your taking the packet trace in the first place?
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
: 10.005 secs data xmit time:0.000 secs
idletime max:7.5 msidletime max:7.4 ms
throughput:117979555 Bps throughput:0 Bps
This was taken at the receiving 10G NIC.
rick jones
-
To unsubscribe from this list: send
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same
.23-rc8 based kernel that has seen a different trace
also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg
It may be that the two
that very question, since SCTP can preserve message
boundaries. He tells me that a zero-length message is not part of SCTP.
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
On Wed, Sep 26, 2007 at 11:10:11AM -0700, Kok, Auke wrote:
Dave Jones wrote:
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same
.23-rc8 based kernel that has seen a different trace
the NIC it might still have too much overhead, but
then does pktgen+driver et al actually fit in an L1 cache?
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
in the receive path, but not the send path for quite possibly decades now.
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
Enable users of ip to specify the times for rtt, rttvar and rto_min
in human-friendly terms a la tc while maintaining backwards
compatability with the previous raw mechanism. Builds upon
David Miller's uncommited patch to set rto_min.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Thanks, I'll
neptune used as an actual module/driver
name, so why niu? To what does niu translate anyway?
sincerely,
rick jones
now left with the quandry of whether to run netperf against a driver for
a card from a .com other than his own or an OEM :) On the plus side
though, this driver has no EULA
+= ETH_HLEN + ip_hdrlen(skb) + tcp_hdrlen(skb);
Might the same thing apply with SKY2_HW_NEW_LE?
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
in is to just send a patch,
don't ask for it.
I will try to work something up after cleaning-up the other listenq
patch to remove the /proc/net/tcp[6] stuff, and an iproute2 patch I have
to allow setting rto_min, rtt and rttvar using tc-esque units.
rick jones
-
To unsubscribe from this list
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.c
Enable users of ip to specify the times for rtt, rttvar and rto_min
in human-friendly terms a la tc while maintaining backwards
compatability with the previous raw mechanism. Builds upon
David Miller's uncommited patch to set rto_min.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
include
or not. also check previous kernel messages
and see what the e1000 driver posted there for link speed messages (as in
e1000:
Link is UP speed XXX duplex YYY)
Shouldn't there then have been at least _some_ collisions reported in
the stats? And perhaps some late collisions?
rick jones
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 10 Sep 2007 11:42:18 -0700
I've been digging around to see about inducing /proc/net/tcp to show
some interesting things for listen sockets (eg backlog depth, its max,
and dropped connection requests). While there I've noticed
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
rick jones
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 17 Sep 2007 11:38:09 -0700
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
Reposting the patch is often better because if you quote it
then the copy I have has
I
use tcpi_unacked and tcpi_sacked.
For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
then covers ss.
rick
-John
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have
John Heffner wrote:
Rick Jones wrote:
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct
doesn't have the idiag_mumble, so
for use in ip.
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
, having
ip provide at least the illusion of what tc does would seem to be a good
thing.
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
Eric Dumazet wrote:
Sridhar Samudrala a écrit :
On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote:
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net
. This is
slightly lower than the value used by the e1000 driver, so it seems
like a safe upper limit.
FWIW the OFED 1.2 bits take the MTU of IPoIB up to 65520 bytes :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
ss command from iproute2 package ( http://linux-net.osdl.org/index.php/Iproute2
)
Problem with /proc/net/tcp is its quadratic time O(N^2) to output N lines...
I could see where that might be a problem.
Rick, could you add this part in your patch, and add my Sign-off-by ?
My pleasure.
I
BTW, what do people think about doing the same thing with the rxqueue
and txqueue's of netstat output?
I dont understand this question, I thought your patch already handled this
(for the txqueue, since rxqueue is already there), as netstat uses
/proc/net/tcp (unfortunatly)
Well, it
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Signed-off-by: Rick Jones [EMAIL
please ignore - I resent the original patch by mistake...grrr.
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
By the way, make sure your Signed-off-by: Rick Jones
[EMAIL PROTECTED] is the first signoff :
You are the main author of this patch, I only reviewed it and added a
contribution.
I just went alphabetically - I take it there is further meaning assigned
to the first person listed? Should I
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL
Pádraig Brady wrote:
Rick Jones wrote:
This was an issue over a decade ago with SPECweb96 benchmarking. The
initial solution was to make the explicit bind() calls and not rely on
the anonymous/ephemeral port space. After that, one starts adding
additional IP's into the mix (at least where
201 - 300 of 666 matches
Mail list logo
