On Thu, 2005-15-12 at 14:07 +0100, Arjan van de Ven wrote: > On Thu, 2005-12-15 at 08:00 -0500, jamal wrote:
> > The big hole punched by DaveM is that of dependencies: a http tcp > > connection is tied to ICMP or the IPSEC example given; so you need a lot > > more intelligence than just what your app is knowledgeable about at its > > level. > > yeah well sort of. You're right of course, but that also doesn't mean > you can't give hints from the other side. Like "data for this socked is > NOT critical important". It gets tricky if you only do it for OOM stuff; > because then that one ACK packet could cause a LOT of memory to be > freed, and as such can be important for the system even if the socket > isn't. > true - but thats _just one input_ into a complex policy decision process. The other is clearly VM realizing some type of threshold has been crossed. The output being a policy decision of what to drop - which gets very interesting if one looks at it being as fine grained as "drop ACKS". The fallacy in the proposed solution is that it simplisticly ties the decision to VM input and the network level input to sockets; as in the example of sockets doing http requests. Methinks what is needed is something which keeps state and takes input from the sockets and the VM and then runs some algorithm to decide what needs to be the final policy that gets installed at the low level kernel (tc classifier level or hardware). Sockets provide hints that they are critical. The box admin could override what is important. cheers, jamal - 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
