|
----- Original Message -----
From: "Julian Anastasov" <ja@xxxxxx>
To: "???" <conan@xxxxxxxxxxxxxxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, September 30, 2000 7:28 AM
Subject: Re: Testlvs and Apache...
[snip]
> > 3. I think there is codes somewhere in the kernel which makes the kernel
> > drop normal
> > packets on some condition.(when it should not)
> > For example, the netdev_max_backlog variable in net/core/dev.c is fixed
to
> > 300.
>
> Yes, there are some checks that take care of packet handling
> using slow CPUs.
>
> > I don't know what the value means and why it's fixed to that value.
>
> Yes, the network tuning is a difficult task.
>
> > Do you have any idea?
>
> If your CPU is fast enough to accept the packets from the
> packet driver and you have enough memory for the LVS entries and for
> the packets you should be able to forward all packets. Of course,
> there are many "if"s. The other thing we must consider is how LVS
> delays the forwarding (and how many incoming packets are dropped
> as result of the delayed handling). That can be tested by simply
> forwarding the packets to the real server(s) without using LVS,
> may be even with kernel without LVS support.
>
1. The variable netdev_max_backlog does not seem to be just for
slow CPUs because it's outside of #ifdef CONFIG_CPU_IS_SLOW block.
Anyway I tried to ignore the netdev_max_backlog check. As a result,
the driver made more warning messages, kernel seemed to process more packets
for a while, but began to drop every packet as before.
2. I also tested the 2.2.16 kernel without LVS support (without any patch
else).
And got the same result. It's not an LVS related problem.
Actually I didn't use Testlvs, but used a packet generating machine named
SmartBit from netcom.
3. Somebody pointed me to check SYN_COOKIE options.
But It seems not to be the reason because the packets generated by SmartBit
were raw IP packets or UDP packets, not TCP packets.
I might have ommited some point while explaining my test configuration.
The configuration is as follows:
smartbit slot#1 <--> Linux machine <--> smartbit slot#2
Each two slots of smartbit sends and receives packets and the linux machine
just routes packets.
The phenomenon that kernel drops every packet(or stop to process packets)
does not occur when I set the linux machine as a bridge (so, not to route
packets)
and this is why I don't believe it's a problem of network devices or
drivers.
Any suggestion for a test or any idea, any doubts will be great help to me!
|
