> Using full-size packets, I assume?
Yes, using full size datagrams.
>
>
> > but the entire machine crashed miserably with TCP traffic. Netfilter is
> > not turn on and so this is just the
> > pure bridging part. The NIC card I used are Intel 82559ER. The kernel
> > messages indicated that the Intel drivers ran out of memory to allocate
its
> > skbuff. This does not happen with the bridging turn off and with the
machine
> > acting as a router or a NAT.
>
> Do you use the driver that comes with the kernel?
Yes, I used the eepro100 driver that came with Linux 2.4.9
>
>
> > I suspect that the bridging code may be spending
> > too long processing the packets in the queue and that the skbuff are not
put
> > back to the transmission queue fast enough. I may be wrong of course.
>
> I think you are. In fact, people have had problems before because the
> bridge code spends less time on processing packets than IP routing does, and
> thus keeps the hardware busier.
>
> Even so, it's just silly that this crashes your machine. I assume you had
> an oops? Can you identify the section of code where your machine crashed
> (I assume in the NIC driver) ?
>
The section is in the NIC driver where it was not able to kmalloc anymore
memory. I traced the entire chain of code from the NIC driver up to the
softnet queue to the bridge, down to the output queue and to the nic card
driver and I am very puzzled as to why there was not enough memory. All
receive and output queues limits the number of skbuff being queued. I suspect
that the kernel's memory menagement is not efficient. Even so I am puzzle as
to why pure routering is OK.
>
> > I did observed, however, that this do not happen on a 700MHz Athon CPU
even
> > though I am using the same NIC cards but I could feel that the Athon
machine
> > becomes sluggish when the traffic is high. Could anybody let me know
whether
> > are there any kind of rate control in the bridging code?
>
> No. You can use output queue control, but that doesn't protect you from
> receive interrupts livelocking your machine. The only 'fix' is to throttle
> your network cards during heavy congestion. See
>
> ftp://robur.slu.se/pub/Linux/tmp/FF-NordUSENIX.pdf
>
>
Even if the card is livelocking the system, it seems to me that the CPU was
able to service the card's interrupt and pass the skbuff to the upper layer
which will drop the packet if the queue exceed a number ( indicated
by /proc/sys/net/core/netdev_max_backlog). Once the packet is dropped, the
memory is immediately freed. Hence there should be no reason why the driver
is unable to allocate memory.
Wilfred
_______________________________________________
Bridge mailing list
[EMAIL PROTECTED]
http://www.math.leidenuniv.nl/mailman/listinfo/bridge
