[ofa-general] Re: [PATCH 2/3][NET_BATCH] net core use batching

[jamal <hadi@cyberus.ca>]

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