On Sat, Mar 18, 2000 at 11:46:23AM +0100, Henner Eisen wrote:
> >>>>> "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?
No. All network schedulers should implement requeue, and the check
is done by the generic queueing code.
> (2) discard the non ppp control frame (which will decrease performance
> of the application having set the high priority intentionally).
.. and there is no guarantee that you will get the control frame
even then.
> (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);
> }
It is probably easier to use a special scheduler for that that calls
the normal scheduler as a child (and make sure PPP devices always
have that special scheduler pushed). That scheduler would make sure
that control packets come always first.
>
> 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...
The PPP ioctls could be replaced by netlink messages to get rid of
the devices (just who wants to do that work?). I'm not sure if it is
worth it.
-Andi
--
This is like TV. I don't like TV.
|