>>>>> "Andi" == Andi Kleen <ak@xxxxxx> writes:
>> Worse, even if we encode the channel into the skb somehow,
>> flow control is a problem. Flow control works the obvious way,
>> i.e. netif_stop_queue() if all channels are busy and
>> netif_wake_queue() if at least one channel becomes non-busy. So
>> now hard_start_xmit() might give us the control frame for a
>> specific channel, which could still be busy though, because we
>> just know that (any) one channel is non-busy.
Andi> Just return 1 then and sch_generic will requeue the packet.
Does this "return 1" depend on a special network scheduler beeing
attached to the netif?
Although I also think that passing (and queuing) isdn_ppp control
frames via the the standard netdevice interface (there should be no
internal queues in ppp, only in the ppp netdevice's network scheduler
as in the hardware) would be the cleanest solution, I see yet another
little problem: If we need to pass a control frame while the netif is
busy, we must rely on the network scheduler to queue the ppp control
at the head of all output frames. Otherwise, (e.g. if another frame
with the same priority is already queued), doing netif_wake_queue()
will pass us the wrong frame first. I see several posibilities:
When netif is in the 'await xmit ppp control frame' state an a non-ppp
control frame is passed
(1) send the non-control frame first (which will delay the ppp
control frame) or
(2) discard the non ppp control frame (which will decrease performance
of the application having set the high priority intentionally).
(3) requeue the non ppp control frame using dev_queue_xmit() and return 0;
(4) pppd queued the ppp control frame not with dev_queue_xmit() but with
a special dev_queue_xmit_first() which would ensure that the frame
is send before all other currently queued frames. The network scheduler
would provide a special q->enqueue_first() method to support this such
that dev_queue_xmit_first() would look like this:
if (q->enqueue_first){
q->enqueue_first(skb);
} else {
q->enqueue(skb);
}
Standard dev_queue_xmit() would remain unchanged such that fast
path is not affected.
BTW: It seems that even more simplifications in all ppp drivers could
result from using the standard netdevice interface also for ppp
control frames. If received control frames were also passed upstream
via netif_rx(), we could get rid of a special /dev/[i]ppp* devices and
all the related code in the ppp drivers. pppd could just send and
receive the ppp control frames via a PF_PACKET socket. (Well, we
still need the /dev/*ppp* files for supporting the ppp ioctl()s, but
all the code dealing with reading, writing and queueing control
frames could be removed.) Well, but this seems to be 2.5.x issue...
Henner
|