On Thu, Mar 16, 2000 at 10:14:31AM +0100, Kai Germaschewski wrote:
> 1) Take the supervisory frames and stuff them into the network queue,
> using TC_PRIO_CONTROL and dev_queue_xmit(). (That's what syncppp.c does)
> 2) Lock the xmit path explicitely.
I think (1) is much cleaner
>
> Additional constraints: multi link has to be considered as well, e.g.
> bundling two physical B-channels into one net interface.
>
> This particularly means that the supervisory frames are sometimes bound to
> a specific channel, we would loose that information using
> dev_queue_xmit().
You could put that information into the skb's cb structure. TCP uses it for
similar purposes. It is currently 48 bytes. It is free to use for you.
>
> 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.
Just return 1 then and sch_generic will requeue the packet.
>
> Locking the xmit path ourselves seems like somewhat duplicate effort, but
> I can't think of any better way. BTW: which spinlock kind should be used
> for code which can be called from user process, hard_start_xmit() and a
> task_queue? spinlock_bh() is not documented in
> Documentations/spinlocks.txt, but I guess that's the right one?
Yes.
-Andi
--
This is like TV. I don't like TV.
|