On Mon, 2007-08-10 at 18:41 -0700, David Miller wrote: > I also want to point out another issue. Any argument wrt. reordering > is specious at best because right now reordering from qdisc to device > happens anyways. > > And that's because we drop the qdisc lock first, then we grab the > transmit lock on the device and submit the packet. So, after we > drop the qdisc lock, another cpu can get the qdisc lock, get the > next packet (perhaps a lower priority one) and then sneak in to > get the device transmit lock before the first thread can, and > thus the packets will be submitted out of order. >
You forgot QDISC_RUNNING Dave;-> the above cant happen. Essentially at any one point in time, we are guaranteed that we can have multiple cpus enqueueing but only can be dequeueing (the one that managed to grab QDISC_RUNNING) i.e multiple producers to the qdisc queue but only one consumer. Only the dequeuer has access to the txlock. > This, along with other things, makes me believe that ordering really > doesn't matter in practice. And therefore, in practice, we can treat > everything from the qdisc to the real hardware as a FIFO even if > something else is going on inside the black box which might reorder > packets on the wire. I think it is important to get the scheduling right - estimations can be a last resort. For example, If i have voip competing for the wire with ftp on two different rings/cpus and i specified that voip should be more important i may consider equipment faulty if it works "most of the time" (when ftp is not clogging the wire) and at times i am asked to repeat what i just said. 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
