Hello!
> >> 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.
Alert!!! Try to avoid this. This system has _no_ support for multiple
hardware queues. Essentially, you have two choices: to send control
frames internally without dev_queue_xmit() (it is easy), or to move
channel demultiplexing to special qdisc (f.e. as sch_atm does).
It is still not clear how support for multiple hardware queues
can be organized. I am inclined to believe that it is simply
not well-defined task. Probably, it is better to try to move
channel multiplexing out of hardware level.
> Andi> Just return 1 then and sch_generic will requeue the packet.
And also it will send it immediately again, if tbusy was not set,
or block whole device, if it is set. No, it will not help with multiple
links.
> 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(),
It is not related problem. Just add support for this to device
and you will be able to receive/send such frames via packet socket.
And it does not solve your problem at all.
Alexey
|