From: "Nathanael Nerode" <[EMAIL PROTECTED]>
Date: Sun, 17 Jul 2005 07:55:45 -0400
> This is partly for the purpose of doing firmware loading in the future,
> but it's also a matter of tidiness.
So make the change when we do the loading like that in the
future.
The fact that you are forcing the
Thomas Graf wrote:
@@ -535,7 +530,6 @@ static struct meta_ops __meta_ops[TCF_ME
[META_ID(TCINDEX)] = META_FUNC(int_tcindex),
#ifdef CONFIG_NET_CLS_ACT
[META_ID(TCVERDICT)]= META_FUNC(int_tcverd),
- [META_ID(TCCLASSID)]
In 2.4 AFAIK, we could utilize multiple CPUs for
receive processing if there were two/ more NICs that
were doing receives but not if there is only 1 NIC.
Has anything changed with regards to this aspect in
2.6?.
Are there any other heuristics / criteria that can be
used to distribute interrupts ac
* Patrick McHardy <[EMAIL PROTECTED]> 2005-07-17 04:09
> Kill skb->tc_classid. It leaves a hole on 64 bit machines, I didn't
> try to plug it since with all the planned changes we probably need
> some restructuring at the end anyway.
I have no objections to this, looks perfectly
fine to me.
> @@
John Que wrote:
Hello,
I wrote a simple , user space program (in "C") which opens 400
UDP sockets ; each of them sends a message.
I saw in the sniffer that many packets are not sent.
I am working with 2.4.20-8 kernel.
I am creating 400 DIFFERENT instances of socket
in the usual way : so
Andy Furniss wrote:
Hmm - I did some testing on old kernels, though I know I sorted it to
2ms I haven't got that kernel anymore and setting a vanilla 2.4.26 to hz
500 made the forwarded traffic cycle with 5ms not 2ms, local doesn't
cycle but isn't constant and gives 5ms varience.
Running the
Hello,
I wrote a simple , user space program (in "C") which opens 400
UDP sockets ; each of them sends a message.
I saw in the sniffer that many packets are not sent.
I am working with 2.4.20-8 kernel.
I am creating 400 DIFFERENT instances of socket
in the usual way : socket(AF_INET,SOCK_
