Nuutti Kotivuori wrote:
> As a workaround to the problem, I've added the IFF_ONE_QUEUE option
> to all the places that open a tap device (namely tunctl, uml_net and
> uml_router). The patch is attached. But the actual problem should
> most likely be fixed once found.
Just a heads up here to the UML folks in case it was missed - with the
current code, packet delivery to UML machines using tuntap driver
*will* mess up (stall totally or major bursts of lag) if more than 10
packets are queued to UML at a time.
This will happen if Linux reassembles packets (connection tracking is
enabled) and a packet of around 17000 bytes or more arrives, or if UML
is given packets faster than it can handle them (not very likely to
happen if the packets are received from a 100Mbit network, and not
generated locally, unless there is heavy load on the machine).
So this is a real problem, for which the patch given is a decent
workaround, as it works perfectly and only changes things if one
employs QoS on the tap device itself.
Ofcourse, the actual cause for this should be fixed (SIGIO mess up or
whatever it is).
From: Jeff Dike <jdike@ad...> - 2005-02-08 22:29:01
> ust a heads up here to the UML folks in case it was missed - with the
> current code, packet delivery to UML machines using tuntap driver
> *will* mess up (stall totally or major bursts of lag) if more than 10
> packets are queued to UML at a time.
It wasn't missed. Someone else posted
that networking freezes until a character is typed on the console.
This is a clear sign of the SIGIO missing some traffic and letting it sit
on the host until some other IO happens.
> Ofcourse, the actual cause for this should be fixed (SIGIO mess up or
> whatever it is).
Yup. It does look like there's some sort of race in the SIGIO handler.