When 'system_in_emergency' flag is set, drop any incoming packets that belong
to non-critical sockets as soon as can determine the destination socket. This
is necessary to prevent incoming non-critical packets to consume memory from
critical page pool.
Introduce a new socket option SO_CRITICAL to mark a socket as critical.
This socket option takes a integer boolean flag that can be set using
setsockopt() and read with getsockopt().
---
include/asm-i386/socket.h|2 ++
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority communications over a critical socket
to succeed even under very low memory conditions that last for a couple of
minutes. It uses the critical page pool facility provided by
I would appreciate any feedback or comments on this approach.
Maybe I'm missing something but wouldn't you need an own critical
pool (or at least reservation) for each socket to be safe against deadlocks?
Otherwise if a critical sockets needs e.g. 2 pages to finish something
and 2 critical
On Mer, 2005-12-14 at 01:12 -0800, Sridhar Samudrala wrote:
Pass __GFP_CRITICAL flag with all allocation requests that are critical.
- All allocations needed to process incoming packets are marked as CRITICAL.
This includes the allocations
- made by the driver to receive incoming
David S. Miller wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 12 Dec 2005 12:03:22 -0800
-d32 = d32 / HZ;
-
/* (wmax-cwnd) * (srtt3 / HZ) / c * 2^(3*bictcp_HZ) */
-d64 = (d64 * dist * d32) (count+3-BICTCP_HZ);
-
-/* cubic root */
-d64
Alan Cox wrote:
But your user space that would add the routes is not so protected so I'm
not sure this is actually a solution, more of an extended fudge.
Yes, there's no 100% solution -- no matter how much memory you reserve and
how many paths you protect if you try hard enough you can come up
On Tue, Dec 13, 2005 at 06:30:38AM +, Paul Erkkila wrote:
GRE tunnel.
ip tunnel:
tunnel0: gre/ip remote xx.xx.xx.xx local xx.xx.xx.xx ttl 255 key
xx.xx.xx.xx
Checksum in received packet is required.
Checksum output packets.
Thanks. It turns out to be a bug in the GRE layer.
Herbert Xu wrote:
Thanks. It turns out to be a bug in the GRE layer. I added that
bug when I introduced skb_postpull_rcsum.
[GRE]: Fix hardware checksum modification
The skb_postpull_rcsum introduced a bug to the checksum modification.
Although the length pulled is offset bytes, the
Bernd Eckenfels wrote:
Al Boldi wrote:
The current ip / ifconfig configuration is arcane and inflexible. The
reason being, that they are based on design principles inherited from
the last century.
Yes I agree, however note that some of the asumptions are backed up and
required by RFCs.
Hello,
I've been reading the source code for the tg3 module (Broadcom Tigon3
Ethernet card) in the Linux kernel. Specifically, I need to access the
NIC specific statistics, since I have to measure the performance of a
server under heavy network loads. Althought the statistics exported
with
jamal writes:
Essentially the approach would be the same as Robert's old recycle patch
where he doesnt recycle certain skbs - the only difference being in the
case of forwarding, the recycle is done asynchronously at EOT whereas
this is done synchronously upon return from host path.
Michael Tokarev wrote:
[..]
So the question is: is the setup like this one supposed to work at all
in linux?
I know there are other less ugly ways to achieve the same effect, eg
by using GRE/IPIP tunnels and incapsulating the traffic into IPSEC (this
way, we'll have only one transport-mode
On Wed, 2005-12-14 at 17:56 +0100, Aritz Bastida wrote:
How can I find the specs for the Tulip3 NIC?
Most of the statistics counters follow the MIB definitions in the RFCs.
There are a few that are non-standard but should be self-explanatory.
Send me an email if you need more information on
On Wed, 2005-12-14 at 10:22 +0100, Andi Kleen wrote:
I would appreciate any feedback or comments on this approach.
Maybe I'm missing something but wouldn't you need an own critical
pool (or at least reservation) for each socket to be safe against deadlocks?
Otherwise if a critical sockets
On Wed, 2005-12-14 at 11:17 +, Alan Cox wrote:
On Mer, 2005-12-14 at 01:12 -0800, Sridhar Samudrala wrote:
Pass __GFP_CRITICAL flag with all allocation requests that are critical.
- All allocations needed to process incoming packets are marked as CRITICAL.
This includes the
Sridhar Samudrala wrote:
The only reason i made these macros is that i would expect this to a compile
time configurable option so that there is zero overhead for regular users.
#ifdef CONFIG_CRIT_SOCKET
#define SK_CRIT_ALLOC(sk, flags) ((sk-sk_allocation __GFP_CRITICAL) |
flags)
#define
On Wed, 2005-12-14 at 04:12 -0800, Mitchell Blank Jr wrote:
Alan Cox wrote:
But your user space that would add the routes is not so protected so I'm
not sure this is actually a solution, more of an extended fudge.
Yes, there's no 100% solution -- no matter how much memory you reserve and
Has anyone had a chance to review this patch and apply it? I would like
it to make 2.6.15 kernel since it is a bug related to TSO in the driver.
Thanks,
Ayaz
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
It has a lot
more users that compete true, but likely the set of GFP_CRITICAL users
would grow over time too and it would develop the same problem.
No, because the critical set is determined by the user (by setting
the socket flag).
The receive side has some things marked as
On Wed, 2005-12-14 at 19:38 +0100, Aritz Bastida wrote:
Thank you for your email. But could you tell me what RFC specifically?
Is it RFC1284? The counters I am looking for are:
These are custom counters not from any RFCs.
dma_writeq_full
DMA write queue full - meaning host is not
On 12/14/05, Sridhar Samudrala [EMAIL PROTECTED] wrote:
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority communications over a critical socket
to succeed even under very low memory conditions that last for a couple of
Carl-Daniel Hailfinger [EMAIL PROTECTED] :
[...]
Performance with nttcp was approximately at 135 MBit/s in
both directions.
Both cards were connected directly with a CAT5e cable.
Enabling/disabling NAPI didn't have any measurable effect.
Are these results expected, and if so, is there any
Jesper Juhl wrote:
To be a little serious, it sounds like something that could be used to
cause trouble and something that will lose its usefulness once enough
people start using it (for valid or invalid reasons), so what's the
point...
It could easily be a user-configurable option in an
Jesper Juhl wrote:
On 12/14/05, Sridhar Samudrala [EMAIL PROTECTED] wrote:
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority communications over a critical socket
to succeed even under very low memory conditions that last for
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:16:29 +1100
[GRE]: Fix hardware checksum modification
The skb_postpull_rcsum introduced a bug to the checksum modification.
Although the length pulled is offset bytes, the origin of the pulling
is the GRE header, not the IP
This patch removes ths unused function xdr_decode_string().
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Neil Brown [EMAIL PROTECTED]
Acked-by: Charles Lever [EMAIL PROTECTED]
---
include/linux/sunrpc/xdr.h |1 -
net/sunrpc/xdr.c | 21 -
2 files
On Wed, 2005-12-14 at 20:49 +, James Courtier-Dutton wrote:
Jesper Juhl wrote:
On 12/14/05, Sridhar Samudrala [EMAIL PROTECTED] wrote:
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority communications over a critical
Sridhar Samudrala wrote:
On Wed, 2005-12-14 at 20:49 +, James Courtier-Dutton wrote:
Jesper Juhl wrote:
On 12/14/05, Sridhar Samudrala [EMAIL PROTECTED] wrote:
These set of patches provide a TCP/IP emergency communication mechanism that
could be used to guarantee high priority
Dave,
I tested these together, but let me know if you want me to
split these into a few pieces, though they'll probably conflict with
each other. :-)
The below jumbo patch fixes the following problems in MLDv2.
1) Add necessary ntohs to recent pskb_may_pull check [breaks
all
Hi david all,
As implemented now, the default memory allocated in net.core.optmem_max
permit
to join up to 320 (S,G) channels per sockets (for IPv6, each channels
cost 32bytes in
net.core.optmem_max), thing is that net.ipv6.mld_max_msf is setting an
hard limit on it, so assuming that you
James Courtier-Dutton wrote:
Have you actually thought about what would happen in a real world senario?
There is no real world requirement for this sort of user land feature.
In memory pressure mode, you don't care about user applications. In
fact, under memory pressure no user applications
Hi Jeremy,
I implemented this functionality in Devicescape's 802.11 stack.
The approach I took was for the driver to install a device specific
qdisc as the root qdisc on the device. This root qdisc's purpose is to
expose the hardware queues directly, so other qdiscs can be attached as
leaf
Hello again,
Sorry Michael, but I am a kind of newbie in this subject and couldnt
understand everything you said clearly. I'm working on my final year
project (I think it's said like that, I mean the project you do when
you finish your degree :P). The purpose of my project is to capture
and
Oh - and re: policy - my 802.11 qdisc first calls out to the tc classify
function - allowing the sysadmin to do what he wants, then if no class
is selected it has a default implementation that reflects the
appropriate 802.11 and WiFi specs for classification.
Of course another implementation
This set of patches:
* precomputes constants used in TCP cubic
* uses Newton/Raphson for cube root
* adds find largest set bit 64 to make initial estimate
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list:
Revised version of patch to pre-compute values for TCP cubic.
* d32,d64 replaced with descriptive names
* cube_factor replaces
srtt[scaled by count] / HZ * ((1 (10+2*BICTCP_HZ)) / bic_scale)
* beta_scale replaces
8*(BICTCP_BETA_SCALE+beta)/3/(BICTCP_BETA_SCALE-beta);
Index: net-2.6.16/include/asm-x86_64/bitops.h
===
--- net-2.6.16.orig/include/asm-x86_64/bitops.h
+++ net-2.6.16/include/asm-x86_64/bitops.h
@@ -340,6 +340,20 @@ static __inline__ unsigned long __ffs(un
return word;
}
+/*
+
Replace cube root algorithim with a faster version using Newton-Raphson.
Surprisingly, doing the scaled div64_64 is faster than a true 64 bit
division on 64 bit CPU's.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- net-2.6.16.orig/net/ipv4/tcp_cubic.c
+++ net-2.6.16/net/ipv4/tcp_cubic.c
Index: bic-2.6/include/linux/bitops.h
===
--- bic-2.6.orig/include/linux/bitops.h
+++ bic-2.6/include/linux/bitops.h
@@ -76,6 +76,15 @@ static __inline__ int generic_fls(int x)
*/
#include asm/bitops.h
+
+static inline int
From: Hoerdt Mickael [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 23:38:56 +0100
As implemented now, the default memory allocated in net.core.optmem_max
permit
to join up to 320 (S,G) channels per sockets (for IPv6, each channels
cost 32bytes in
net.core.optmem_max), thing is that
Changing the MTU size causes the receiver to have to reallocate buffers.
If this allocation fails, then we need to return an error, and take
the device offline. It can then be brought back up or reconfigured
for a smaller MTU.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
Enough changes for one version.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -43,7 +43,7 @@
#include skge.h
#define DRV_NAME skge
-#define DRV_VERSION1.2
+#define DRV_VERSION
If changing ring parameters is unable to allocate memory, we need
to return an error and take the device down.
Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=5715
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@
Change the speed settings doesn't need to cause link to go down/up.
It can be handled by doing the same logic as nway_reset.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -88,15 +88,14 @@ MODULE_DEVICE_TABLE(pci,
--
-
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
Don't need to keep Yukon-2 related definitions around for Skge
driver that is only for Yukon-1 and Genesis.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/skge.h
+++ skge-2.6/drivers/net/skge.h
@@ -475,18 +475,6 @@ enum {
Q_T2= 0x40, /* 32 bit
On Wed, 2005-12-14 at 14:39 -0800, Ben Greear wrote:
James Courtier-Dutton wrote:
Have you actually thought about what would happen in a real world senario?
There is no real world requirement for this sort of user land feature.
In memory pressure mode, you don't care about user
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Tue, 13 Dec 2005 16:57:00 -0800
Receiving VLAN packets over a device (without VLAN assist) that is
doing hardware checksumming (CHECKSUM_HW), causes errors because the
VLAN code forgets to adjust the hardware checksum.
Signed-off-by: Stephen
David S. Miller wrote:
From: John Ronciak [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 11:48:46 -0800
Copybreak probably shouldn't be used in routing use cases.
I think even this is arguable, routers route a lot more than
small 64-byte frames. Unfortunately, that is what everyone
uses for packet
On Wed, 2005-14-12 at 16:48 -0800, David S. Miller wrote:
Please have a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=4952
It should look familiar.
It is - the soup nazi got involved on that bug ;-
http://marc.theaimsgroup.com/?l=linux-netdevm=113070963711648w=2
We were
On Thu, 2005-12-15 at 00:07 +0100, Aritz Bastida wrote:
rx_threshold_hit
Rx max coalescing frames threshold hit.
Well, I didn't understand what is this threshold for
This counter counts the number of times rx packets have reached the max
rx coalesced frames setting before an
On Wed, Dec 14, 2005 at 09:55:45AM -0800, Sridhar Samudrala wrote:
On Wed, 2005-12-14 at 10:22 +0100, Andi Kleen wrote:
I would appreciate any feedback or comments on this approach.
Maybe I'm missing something but wouldn't you need an own critical
pool (or at least reservation) for each
On Wed, Dec 14, 2005 at 08:30:23PM -0800, David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 19:39:37 -0800
I think we need a global receive pool and per-socket send pools.
Mind telling everyone how you plan to make use of the global receive
pool when the
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 21:02:50 -0800
There needs to be two rules:
iff global memory critical flag is set
- allocate from the global critical receive pool on receive
- return packet to global pool if not destined for a socket with an
attached send
On Wed, Dec 14, 2005 at 08:30:23PM -0800, David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 19:39:37 -0800
I think we need a global receive pool and per-socket send pools.
Mind telling everyone how you plan to make use of the global receive
pool when the
David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 21:02:50 -0800
There needs to be two rules:
iff global memory critical flag is set
- allocate from the global critical receive pool on receive
- return packet to global pool if not destined for a socket with
On Wed, 14 Dec 2005 21:23:09 -0800 (PST)
David S. Miller [EMAIL PROTECTED] wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 21:02:50 -0800
There needs to be two rules:
iff global memory critical flag is set
- allocate from the global critical receive pool on receive
On Thu, 15 Dec 2005 06:42:45 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Dec 14, 2005 at 08:30:23PM -0800, David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 19:39:37 -0800
I think we need a global receive pool and per-socket send pools.
Mind
On Wed, 14 Dec 2005, David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 19:39:37 -0800
I think we need a global receive pool and per-socket send pools.
Mind telling everyone how you plan to make use of the global receive
pool when the allocation happens in
60 matches
Mail list logo
