From: Greg Banks <[EMAIL PROTECTED]>
Date: Thu, 02 Feb 2006 18:31:49 +1100
> On Thu, 2006-02-02 at 17:45, Andi Kleen wrote:
> > Normally TSO was supposed to fix that.
>
> Sure, except that the last time SGI looked at TSO it was
> extremely flaky. I gather that's much better now, but TSO
> still
On Thursday 02 February 2006 08:31, Greg Banks wrote:
> The tg3 driver uses small hardcoded values for the RXCOL_TICKS
> and RXMAX_FRAMES registers, and allows "ethtool -C" to change
> them. SGI's solution is do is ship a script that uses ethtool
> at boot to tune rx-usecs, rx-frames, rx-usecs-ir
On Thursday 02 February 2006 01:34, David S. Miller wrote:
> There really is no sane way to help these guys out who have used
> the wildcard protocol number value for a real protocol.
I think they want to use it as a wildcard.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe net
On Thursday 02 February 2006 01:15, Stephen Hemminger wrote:
> Is this supposed to work? Or is it a just something linux
> doesn't implement?
He wants to use a packet socket with ntohs(ETH_P_IP) instead.
I vaguely remember some crazy SUS comittee proposed
to use 0 as a pseudo portable way to impl
On Thursday 02 February 2006 00:50, David S. Miller wrote:
>
> Why not concentrate your thinking on how to make it can be made to
> _work_ instead of punching holes in the idea? Isn't that more
> productive?
What I think would be very practical to do would be to try to
replace the socket rx que
On Thursday 02 February 2006 00:08, Jeff Garzik wrote:
> Definitely not. POSIX AIO is far more complex than the operation
> requires,
Ah, I sense strong a NIH field.
> and is particularly bad for implementations that find it wise
> to queue a bunch of to-be-filled buffers.
Why? lio_listio se
On Thu, 2006-02-02 at 17:45, Andi Kleen wrote:
> There was already talk some time ago to make NAPI drivers use
> the hardware mitigation again. The reason is when you have
> a workload that runs below overload and doesn't quite
> fill the queues and is a bit bursty, then NAPI tends to turn
> on/o
Andi Kleen wrote:
There was already talk some time ago to make NAPI drivers use
the hardware mitigation again. The reason is when you have
This was discussed on the netdev list, and the conclusion was that you
want both NAPI and hw mitigation. This was implemented in a few
drivers, at least
On Thursday 02 February 2006 07:49, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Thu, 2 Feb 2006 07:45:26 +0100
>
> > Don't think it was ever implemented though. In the end we just
> > eat the slowdown in that particular load.
>
> The tg3 driver uses the chip interrupt miti
On Thursday 02 February 2006 00:37, Mitchell Blank Jr wrote:
> Jeff Garzik wrote:
> > Once packets classified to be delivered to a specific local host socket,
> > what further operations are require privs? What received packet data
> > cannot be exposed to userspace?
>
> You just need to make sure
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
> Sent: Wednesday, February 01, 2006 10:45 PM
> There was already talk some time ago to make NAPI drivers use
> the hardware mitigation again. The reason is when you have a
> workload
On Thursday 02 February 2006 04:19, Greg Banks wrote:
> On Thu, 2006-02-02 at 14:13, David S. Miller wrote:
> > From: Greg Banks <[EMAIL PROTECTED]>
> > Date: Thu, 02 Feb 2006 14:06:06 +1100
> >
> > > On Thu, 2006-02-02 at 13:46, David S. Miller wrote:
> > > > I know SAMBA is using sendfile() (when
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 2 Feb 2006 07:45:26 +0100
> Don't think it was ever implemented though. In the end we just
> eat the slowdown in that particular load.
The tg3 driver uses the chip interrupt mitigation to help
deal with the SGI NUMA issues resulting from NAPI.
-
To
On Thursday 02 February 2006 02:53, Greg Banks wrote:
> On Thu, 2006-02-02 at 08:11, David S. Miller wrote:
> > Van is not against NAPI, in fact he's taking NAPI to the next level.
> > Softirq handling is overhead, and as this work shows, it is totally
> > unnecessary overhead.
>
> I got the impres
On Wed, Feb 01, 2006 at 08:54:36PM -0500, John W. Linville wrote:
> On Wed, Feb 01, 2006 at 04:37:53PM -0500, Neil Horman wrote:
> >
> > As promised, new patch attached, that makes accepting gratuitous arps a
> > dynamically configurable option. Tested successfully by me.
>
> Probably need some
On Thu, 2006-02-02 at 14:32, David S. Miller wrote:
> I see.
>
> Maybe we can be smarter about how the write(), CORK, sendfile,
> UNCORK sequence is done.
>From the NFS server's point of view, the ideal interface would
be to pass an array of {page,offset,len} tuples, covering up to
around 1 MiB+1
On Wed, 01 Feb 2006 10:38:28 +0100 Jean-Baptiste Note wrote:
> Hi Denis,
>
> > Do you have a "HOWTO sniff USB under Windows" or URL to it?
> > May be helpful for other potential developers.
> >
>
> One page which I found very usefull for prism54softmac USB sniffing
> under windows is this one :
From: Greg Banks <[EMAIL PROTECTED]>
Date: Thu, 02 Feb 2006 14:19:43 +1100
> Multiple trips down through TCP, qdisc, and the driver for each
> NFS packet sent: one for the header and one for each page. Lots
> of locks need to be taken and dropped, all this while multiple nfds
> on multiple CPUs a
On Thu, 2006-02-02 at 14:13, David S. Miller wrote:
> From: Greg Banks <[EMAIL PROTECTED]>
> Date: Thu, 02 Feb 2006 14:06:06 +1100
>
> > On Thu, 2006-02-02 at 13:46, David S. Miller wrote:
> > > I know SAMBA is using sendfile() (when the client has the oplock held,
> > > which basically is "always
From: Greg Banks <[EMAIL PROTECTED]>
Date: Thu, 02 Feb 2006 14:06:06 +1100
> On Thu, 2006-02-02 at 13:46, David S. Miller wrote:
> > I know SAMBA is using sendfile() (when the client has the oplock held,
> > which basically is "always"), is NFS doing so as well?
>
> NFS is an in-kernel server, an
On Thu, 2006-02-02 at 13:46, David S. Miller wrote:
> I know SAMBA is using sendfile() (when the client has the oplock held,
> which basically is "always"), is NFS doing so as well?
NFS is an in-kernel server, and uses sock->ops->sendpage directly.
> Van does have some ideas in mind for TX net ch
From: Greg Banks <[EMAIL PROTECTED]>
Date: Thu, 02 Feb 2006 12:53:14 +1100
> I got the impression that his code was dynamically changing the
> e1000 interrupt mitigation registers in response to load, in
> other words using the capabilities of the hardware in a way that
> NAPI deliberately avoids
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 17:32:24 -0800
How large is "the bulk?"
The prequeue is always enabled when the app has blocked
on read().
Actually I meant in terms of percentage of the cycles to process the packet
rather than frequency
On Wed, Feb 01, 2006 at 04:37:53PM -0500, Neil Horman wrote:
>
> As promised, new patch attached, that makes accepting gratuitous arps a
> dynamically configurable option. Tested successfully by me.
Probably need some documentation for this, no?
John
--
John W. Linville
[EMAIL PROTECTED]
-
To
On Thu, 2006-02-02 at 08:11, David S. Miller wrote:
> Van is not against NAPI, in fact he's taking NAPI to the next level.
> Softirq handling is overhead, and as this work shows, it is totally
> unnecessary overhead.
I got the impression that his code was dynamically changing the
e1000 interrupt m
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 17:32:24 -0800
> How large is "the bulk?"
The prequeue is always enabled when the app has blocked
on read().
> > Ie. ACK goes out as fast as we can context switch
> >to the app receiving the data. This feedback makes all senders
>
In article <[EMAIL PROTECTED]> (at Wed, 01 Feb 2006 17:28:10 -0800), Roland
Dreier <[EMAIL PROTECTED]> says:
> Sorry to distract everyone from the VJ channel discussion, but on the
> other hand it looks like Dave is back... I'm resending this because
> I'd really like to get this problem fixed bu
David> It's sitting in my backlog, and will be a net-2.6.17 issue
David> not a net-2.6.16 one as we're in bug fix mode there.
David> Sorry if you need this in 2.6.16, but that's not really
David> practical.
No, that's fine... I was just resending in case you were using RED to
mana
Maybe I'm not sufficiently clued-in, but in broad handwaving terms,
it seems today that all three can be taking place in parallel for a
given TCP connection. The application is doing its
application-level thing on request N on one CPU, while request N+1
is being processed by TCP on another CPU, w
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 17:28:10 -0800
> Sorry to distract everyone from the VJ channel discussion, but on the
> other hand it looks like Dave is back... I'm resending this because
> I'd really like to get this problem fixed but I want to make sure
> we're do
Sorry to distract everyone from the VJ channel discussion, but on the
other hand it looks like Dave is back... I'm resending this because
I'd really like to get this problem fixed but I want to make sure
we're doing it the right way. So either an ACK or a NAK with guidance
would be great...
This
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 16:39:00 -0800
> My questions are meant to see if something is even a roadblock in
> the first place.
Fair enough.
> Maybe I'm not sufficiently clued-in, but in broad handwaving terms,
> it seems today that all three can be taking place
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 15:50:38 -0800
[ What sucks about this whole thread is that only folks like
Jeff and myself are attempting to think and use our imagination
to consider how some roadblocks might be overcome ]
My question
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 16:15:04 -0800
> Is this supposed to work? Or is it a just something linux
> doesn't implement?
Protocol number zero is reserved, that's f.e. why nothing takes up
that slot in /etc/services.
This is how you represent "any" protoco
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 16:12:14 -0800
> The bigger problem I see is scalability. All those mmap rings have to
> be pinned in memory to be useful. It's fine for a single smart application
> per server environment, but in real world with many dumb thread m
Is this supposed to work? Or is it a just something linux
doesn't implement?
Date: Wed, 1 Feb 2006 12:48:03 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 5990] New: call to socket(AF_INET, SOCK_RAW, IPPROTO_IP);
http://bugzilla.kernel.org/show_bug.cgi?id=5990
Sum
On Wed, 01 Feb 2006 15:42:39 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed, 1 Feb 2006 23:55:11 +0100
>
> > On Wednesday 01 February 2006 21:26, Jeff Garzik wrote:
> > > Andi Kleen wrote:
> > > > But I don't think Van's design is suppo
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 15:50:38 -0800
[ What sucks about this whole thread is that only folks like
Jeff and myself are attempting to think and use our imagination
to consider how some roadblocks might be overcome ]
> If the TCP processing is put in the
It almost feels like the channel concept wants a "thread per
connection" model?
No, it means only that your application must be asynchronous -- which
all modern network apps are already.
The INN model of a single process calling epoll(2) for 800 sockets
should continue to work, as should th
From: Mitchell Blank Jr <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 15:37:04 -0800
> So I agree that this would have to be CAP_NET_ADMIN only.
I'm drowning in all of this pessimism folks.
Why not concentrate your thinking on how to make it can be made to
_work_ instead of punching holes in the ide
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 23:55:11 +0100
> On Wednesday 01 February 2006 21:26, Jeff Garzik wrote:
> > Andi Kleen wrote:
> > > But I don't think Van's design is supposed to be exposed to user space.
> >
> > It is supposed to be exposed to userspace AFAICS.
>
> Th
Jeff Garzik wrote:
> Once packets classified to be delivered to a specific local host socket,
> what further operations are require privs? What received packet data
> cannot be exposed to userspace?
You just need to make sure that you don't leak data from other peoples
sockets. Two issues I se
But people who care about the performance of their networking apps are
likely to want to switch over to this new userspace networking API, over
the next decade, I think.
Yet there needs to be some cross-platform commonality for the API yes? That was
the main thrust behind my simplistic aski
Andi Kleen wrote:
On Wednesday 01 February 2006 21:26, Jeff Garzik wrote:
Andi Kleen wrote:
But I don't think Van's design is supposed to be exposed to user space.
It is supposed to be exposed to userspace AFAICS.
Then it's likely insecure and root only, unless he knows some magic
that w
Rick Jones wrote:
what are the implications for having the application churning away doing
application things while TCP is feeding it data? Or for an application
that is processing more than one TCP connection in a given thread?
It almost feels like the channel concept wants a "thread per con
Rick Jones wrote:
Jeff Garzik wrote:
Key point 1:
Van's slides align closely with the design that I was already working
on, for zero-copy RX.
To have a fully async, zero copy network receive, POSIX read(2) is
inadequate.
Is there an aio_read() in POSIX adequate to the task?
Definitel
If I heard correctly, the default of
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts has changed from 0 to 1.
You'll want to set that back to 0.
HTH,
Bruce.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Ketrenos
Sent: Wednesday, February 01, 2006 2
On Wednesday 01 February 2006 21:26, Jeff Garzik wrote:
> Andi Kleen wrote:
> > But I don't think Van's design is supposed to be exposed to user space.
>
> It is supposed to be exposed to userspace AFAICS.
Then it's likely insecure and root only, unless he knows some magic
that we don't.
I hope
On Wednesday 01 February 2006 22:11, David S. Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed, 1 Feb 2006 19:28:46 +0100
>
> > http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
>
> I did a writeup in my blog about all of this, another good
> reason to actively follow my blog
On Wed, 2006-02-01 at 00:54 -0800, [EMAIL PROTECTED] wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Andrew, please drop it for now. It has issues on sparc64 that I need to
have a look at.
Ben.
> On my latest laptop, I've had occasional PHY dead on wakeup from sleep...
> the PHY would
SCTP used to "fast retransmit" a TSN every time we hit the number
of missing reports for the TSN. However the Implementers Guide
specifies that we should only "fast retransmit" a given TSN once.
Subsequent retransmits should be timeouts only. Also change the
number of missing reports to 3 as per t
Ian McDonald <[EMAIL PROTECTED]> wrote:
> On 2/1/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
>> Ian McDonald <[EMAIL PROTECTED]> wrote:
>> >
>> > --- a/net/core/sock.c
>> > +++ b/net/core/sock.c
>> > @@ -162,7 +162,8 @@ static int sock_set_timeout(long *timeo_
>> >if (tv.tv_sec == 0 && tv.tv_
Hey Jeff,
I know you're backlogged, but if you could consider pulling from branch
'for-jeff' at git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
I'd appreciate it a lot.
The content is described below. It merges fine with your 'upstream-fixes'
branch.
Francois Romieu
8139too: fix a
At the risk of being told to launch myself towards a body of water...
So, sort of linking with the data about saturating a GbE both ways on a single
TCP connection, and how it required binding netperf to the CPU other than the
one taking interrupts... If channels are taken to their limit, and t
On Monday 30 January 2006 20:21, Ian McDonald wrote:
> On 1/31/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> > From: John Heffner <[EMAIL PROTECTED]>
> > Date: Tue, 06 Dec 2005 14:42:53 -0500
> >
> > > I'd like to get a few people at least to look this over, and maybe give
> > > it a try. One r
On Tuesday 31 January 2006 01:12, Andi Kleen wrote:
> > > 1) Get rid of the debugging printk()'s
>
> I would suggest to replace them with statistic counters for netstat -s
I just tried adding a few linux-mib entries for this, and netstat started
dying. There is a hard-coded limit of 1024 in nets
As promised, new patch attached, that makes accepting gratuitous arps a
dynamically configurable option. Tested successfully by me.
Thanks & Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
include/linux/inetdevice.h |1 +
include/linux/sysctl.h |3 ++-
net/ipv4/arp.c
Fixed sparse warnings mainly due to lack of __iomem.
---
commit 682307be628635abd497a77bf26aa7ba6b5593e9
tree ac3156a394371416519566a8e4aff345575e8f33
parent 690e2cb75eb8fc41413a9e9f85919b275b4164a9
author Kumar Gala <[EMAIL PROTECTED]> Wed, 01 Feb 2006 15:17:45 -0600
committer Kumar Gala <[EMAIL
From: Venkat Yekkirala <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 10:43:09 -0500
> I see this uses netlink which uses wait queues. Could using wait queues be a
> solution to the PF_KEY problem?
PF_KEY is always going to do badly here because it wants to stuff the
entire response into the socket i
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 01 Feb 2006 14:37:46 -0500
> So, I am not concerned with slideware. These are two good ideas that
> are worth pursuing, even if Van produces zero additional output.
Right.
And, to all of you having trouble imagining how else you'd apply these
ne
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 20:50:31 +0100
> On Wednesday 01 February 2006 20:37, Jeff Garzik wrote:
>
> > To have a fully async, zero copy network receive, POSIX read(2) is
> > inadequate.
>
> Agreed, but POSIX aio is adequate.
No, it's a joke.
To do this stu
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 1 Feb 2006 19:28:46 +0100
> http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
I did a writeup in my blog about all of this, another good
reason to actively follow my blog:
http://vger.kernel.org/~davem/cgi-bin/blog.cgi/index.html
Go r
> Yup, that is my current understanding. Heck:
>
> 1. using hrtimers in DCCP
> 2. Jumping into VJ's net channels to implement Eddie Kohler packet
> rings DCCP API
> 3. reviewing Andrea's CCID2 code and merging it
> 4. reviewing Ian's work on using sk_write_queue
> 5. reviewing/merging Andrea's feat
On 2/1/06, Ian McDonald <[EMAIL PROTECTED]> wrote:
> On 2/1/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > Ian McDonald <[EMAIL PROTECTED]> wrote:
> > > *timeo_p = tv.tv_sec*HZ +
> > > +
> > > (tv.tv_usec+(USEC_PER_SEC/HZ-1))/(USEC_PER_SEC/HZ);
> >
> > Is there a
On 2/1/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> Ian McDonald <[EMAIL PROTECTED]> wrote:
> >
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -162,7 +162,8 @@ static int sock_set_timeout(long *timeo_
> >if (tv.tv_sec == 0 && tv.tv_usec == 0)
> >return 0;
> >
Andi Kleen wrote:
But I don't think Van's design is supposed to be exposed to user space.
It is supposed to be exposed to userspace AFAICS.
It's still in the kernel, just in process context.
Incorrect. Its in the userspace app (though usually via a library).
See slides 26 and 27.
But i
This patch adds the kernel component to support the userspace Infiniband/RDMA
connection agent library.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drivers/infiniband/core/Makef
On 2/1/06, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 February 2006 20:37, Jeff Garzik wrote:
>
> > To have a fully async, zero copy network receive, POSIX read(2) is
> > inadequate.
>
> Agreed, but POSIX aio is adequate.
>
> > One needs a ring buffer, similar in API to the mmap'd
> >
Andi writes:
> But I don't think Van's design is supposed to be exposed to user space.
> It's just a better way to implement BSD sockets.
Actually, it can, indeed, go all the way to user space - connecting
channels to the socket layer was one of the intermediate steps.
FWIW, I did an article on
The following patch implements a 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.
It also handles RDMA device hotplug events on be
The following provides an address translation service that maps IP addresses
to Infiniband addresses (GIDs) using IPoIB.
This patch exports ip_dev_find() to locate a net_device given an IP address.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.git/Documentation/dontd
Jeff Garzik wrote:
Key point 1:
Van's slides align closely with the design that I was already working
on, for zero-copy RX.
To have a fully async, zero copy network receive, POSIX read(2) is
inadequate.
Is there an aio_read() in POSIX adequate to the task?
One needs a ring buffer, simila
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cm.c
linux-2.6.ib/drivers/infiniband/core
The following patch provides common handling for marshalling data between
Userspace clients and kernel mode Infiniband drivers.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drive
Here's an updated version of these patches based on feedback. (The license
did not change and continues to match that of the other Infiniband code.)
Please consider for inclusion in 2.6.17.
The following set of patches defines a connection abstraction for Infiniband and
other RDMA devices, and s
I haven't been able to get a TCP connection to saturate a 1Gbps link
in both directions simultaneously. I *have* been able to fully saturate
2 pro/1000 NICs on the same machine using pktgen, so the NIC/driver can
support it if only TCP can run fast enough...
It isn't quite saturating, but:
loi
On Wednesday 01 February 2006 20:37, Jeff Garzik wrote:
> To have a fully async, zero copy network receive, POSIX read(2) is
> inadequate.
Agreed, but POSIX aio is adequate.
> One needs a ring buffer, similar in API to the mmap'd
> packet socket, where you can queue a whole bunch of reads.
Key point 1:
Van's slides align closely with the design that I was already working
on, for zero-copy RX.
To have a fully async, zero copy network receive, POSIX read(2) is
inadequate. One needs a ring buffer, similar in API to the mmap'd
packet socket, where you can queue a whole bunch of r
Also, you have to increase TCP max window size to saturate a 1Gbps link.
You need to increase tcp_rmem[2] on receiver and tcp_wmem[2] on sender.
This is easily done with sysctl. And of course you have to have enough
memory that TCP isn't deciding to throttle you for chewing too much
memory in the
On Wednesday 01 February 2006 19:44, Stephen Hemminger wrote:
>
> Also, you have to increase TCP max window size to saturate a 1Gbps link.
> You need to increase tcp_rmem[2] on receiver and tcp_wmem[2] on sender.
They did all that. Also it's all the same on 2.4
-Andi
-
To unsubscribe from this
On Wednesday 01 February 2006 19:54, you wrote:
> When applying it, I noticed that the dscape branch's bcm43xx is differently
> named than the softmac branch's. Why ? :-)
Both branches can co-exist in one tree (see branch "domesday")
--
Greetings Michael.
pgp5Yp4DHSWEk.pgp
Description: PGP si
John,
> On Wednesday 01 February 2006 10:51, Danny van Dyk wrote:
> > John, please
> >
> > git pull rsync://pitr.amd64.dev.gentoo.org/kugelfang/wireless-2.6.git
> >
> > which will provide this changeset:
> >
> > Danny van Dyk:
> > [bcm43xx] Sync bcm43xx_phy_initb6() with specs
>
> Danny, _pl
On Wed, 1 Feb 2006 19:02:02 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 February 2006 17:52, Ben Greear wrote:
>
> > I haven't been able to get a TCP connection to saturate a 1Gbps link
> > in both directions simultaneously. I *have* been able to fully saturate
> > 2 pro/1000 N
On Wed, 01 Feb 2006 19:33:47 +0100
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
>
> > Why you cannot support autoloading the modules when a specific protocol
> > is needed?
>
> I probably could but it would complicate things a bit - currently only
> the
[EMAIL PROTECTED] (Marco d'Itri) writes:
> Why you cannot support autoloading the modules when a specific protocol
> is needed?
I probably could but it would complicate things a bit - currently only
the protocol module knows about existence of its protocol.
I will look at it, though. Thanks.
--
On Wednesday 01 February 2006 14:48, Leonid Grossman wrote:
> David S. Miller wrote:
>
> > And with Van Jacobson net channels, none of this is going to
> > matter and 512 is going to be your limit whether you like it
> > or not. So this short term complexity gain is doubly not justified.
>
>
On Wednesday 01 February 2006 17:52, Ben Greear wrote:
> I haven't been able to get a TCP connection to saturate a 1Gbps link
> in both directions simultaneously. I *have* been able to fully saturate
> 2 pro/1000 NICs on the same machine using pktgen, so the NIC/driver can
> support it if only TC
Hi,
Thanks, the patch fix the problem for me. :-)
Today is the first time, i will try the jumbo network.
I am very concerned to the result...
The new 6.3.9 driver looks like better! :-)
Cheers,
Janos
- Original Message -
From: "Jesse Brandeburg" <[EMAIL PROTECTED]>
To: "JaniD++" <[EMAI
I managed to get a box running 2.6.16rc1-git4 to spit this out..
Dave
UDP: bad checksum. From 192.168.79.115:43047 to 192.168.76.106:61494 ulen 1083
Badness in dst_release at include/net/dst.h:154 (Not tainted)
[] __kfree_skb+0x36/0xdd
[] ip_frag_destroy+0xe2/0x101 [] ip_de
On Wed, 01 Feb 2006 00:54:37 -0800
[EMAIL PROTECTED] wrote:
>
> From: "Jiri Slaby" <[EMAIL PROTECTED]>
>
> Pci probing functions added, some functions were rewritten. Use PCI_DEVICE
> macro.
>
> Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>
Ashutosh Naik wrote:
On 2/1/06, Ben Greear <[EMAIL PROTECTED]> wrote:
Ashutosh Naik wrote:
Now, I assume that on Gigabit ethernet, I should be getting Line Rate,
which is around 220 MBps. Even the CPU is not getting max-ed out here
and I am at a loss to understand this behaviour.
Make sure
Please don't use that patch.
I have a better non-automated version of the rtnl conversion.
=
This patch turns the RTNL from a semaphore to a new 2.6.16 mutex
and gets rid of some of the leftover legacy.
Signed-off-by: Stephen Hemminger <[
On Wed, 2006-01-02 at 10:43 -0500, Venkat Yekkirala wrote:
> I have tried "ip xfrm policy list" and it dumps all the thousands of rules,
> no problem.
>
> I see this uses netlink which uses wait queues. Could using wait queues be a
> solution to the PF_KEY problem?
>
Give it a shot with wait que
I have tried "ip xfrm policy list" and it dumps all the thousands of rules,
no problem.
I see this uses netlink which uses wait queues. Could using wait queues be a
solution to the PF_KEY problem?
Thanks.
> -Original Message-
> From: jamal [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, Janua
Johannes Berg wrote:
>Recently the deauth packet handler was updated to use a deauth packet
>struct (identical to the auth packet struct) and this now gives a
>
>
To keep readers from getting confused...
ieee80211_deauth is identical to ieee80211_disassoc (not ieee80211_auth)
(The patch is do
On Feb 01, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> a) Currently it consists of mid-layer WAN protocols single module (Cisco
>HDLC, FR etc.) + low-level hardware HDLC card driver (C101, N2, PCI200SYN
>etc.). I'm thinking about splitting the protocol module into separate
>modules -
David S. Miller wrote:
> I haven't found a way to solve the -EFAULT problem, but we should
> fix the ENFILE/EMFILE issue since we can, this has sat on the
> backburner long enough :-)
This seems to be enough.
Is there any valid reason for an application to expect not loosing any
connection
afte
On Wednesday 01 February 2006 10:51, Danny van Dyk wrote:
> John, please
>
> git pull rsync://pitr.amd64.dev.gentoo.org/kugelfang/wireless-2.6.git
>
> which will provide this changeset:
>
> Danny van Dyk:
> [bcm43xx] Sync bcm43xx_phy_initb6() with specs
Danny, _please_ make sure to apply
This patch adds support for the Ethernet controller integrated in the
Atmel AT91RM9200 SoC processor.
Signed-off-by: Andrew Victor <[EMAIL PROTECTED]>
diff -urN linux-2.6.15.orig/drivers/net/arm/Kconfig
linux-2.6.15/drivers/net/arm/Kconfig
--- linux-2.6.15.orig/drivers/net/arm/Kconfig Mon Oc
Thanks for the post:
Here's the /proc/slabinfo output:
slabinfo - version: 2.1
# name
: tunables:
slabdata
ip_conntrack_syn 0 0 64 591 : tunables 120 60
8 : slabdata 0 0 0
ip_fib_alias 9113 32 1131 : tunables
1 - 100 of 127 matches
Mail list logo
