On Fri, Oct 26, 2007 at 05:21:31PM +0200, Jean Delvare wrote:
>
> This is just one way to limit the hash size, there are others; I am not
> familiar enough with the TCP code to decide which is best. Thus, I
> would welcome the proposals of alternatives.
>
Yeah, the existing way of sizing the
On Fri, Aug 24, 2007 at 02:47:11PM -0700, David Miller wrote:
>
> Someone should reference that thread _now_ before this discussion goes
> too far and we repeat a lot of information ..
Here's part of the thread:
http://marc.info/?t=11159530601&r=1&w=2
Also, Jamal's paper may be of i
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
> ...
> 3) On modern systems the incoming packets are processed very fast. Especially
> on SMP systems when we use multiple queues we process only a few packets
> per napi poll cycle. So NAPI does not work very well here a
On Wed, Aug 08, 2007 at 09:46:16AM -0700, Roland Dreier wrote:
>
> Not mmiowb() -- that is for ordering between CPUs, eg on systems like
> Altix where PCI transactions might get reordered in the system fabric
> before reaching the PCI bus.
>
Yes, that's right. This is a continual source of
A colleague of mine found that multicasts with a ttl of 0
can be sent on the wire. This happens if the sender doesn't
belong to the destination multicast group.
With the following the multicast ttl is respected whether
or not the sender belongs to the destination multicast group.
Signed-off-by:
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long,
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
Yes, I have been playing around with the same idea for
doing dynamic resizing of the TCP hashtable.
Did a
On Thu, 14 Dec 2006, Linas Vepstas wrote:
On Wed, Nov 08, 2006 at 07:38:12AM +1100, Benjamin Herrenschmidt wrote:
What about Linas patches to do interrupt mitigation with NAPI polling ?
That didn't end up working ?
It seems to be "working as designed", which is different than "working
as nai
On Wed, 9 Aug 2006, Andi Kleen wrote:
But there's alot of state to update (more or less
atomically, too)
Why does it need to be atomic? It might be enough
to just check a flag and poll for it in the readers and then redo the
lookup.
(I qualified "atomic" with "more or less" :-)
Sure,
On Tue, 8 Aug 2006, David Miller wrote:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 01:23:01 +0200
The problem is to find out what a good boundary is.
The more I think about this the more I lean towards
two conclusions:
1) dynamic table growth is the only reasonable way to
On Wed, 9 Aug 2006, Andi Kleen wrote:
I don't think it makes any sense to continue scaling at all after
some point - you won't get better shorter hash chains anymore and the
large hash tables actually cause problems: e.g. there are situations where we
walk
the complete tables and that take
On Tue, 8 Aug 2006, Andi Kleen wrote:
The hash sizing code needs far more tweaks. iirc it can still allocate
several GB hash tables on large memory systems (i've seen that once in
the boot log of a 2TB system). Even on smaller systems it is usually
too much.
Yes. Linear growth with memory
On Tue, 20 Jun 2006, Rick Jones wrote:
I thought the ID's even in non-fragmented datagrams gave an idea of how many
IP datagrams had been sent along, and so an idea of how "unlikely" it was
that a datagram with holes could be reassembled?
Only fragmented datagrams get counted. This is
On Mon, 13 Mar 2006, Luiz Fernando Capitulino wrote:
BTW Robert, my TODO list for pktgen so far is:
* A new command called 'rem_device' to remove one device at a time
(currently, we can only remove all devices in one shoot with
'rem_devices_all')
This should be very simple to i
14 matches
Mail list logo
