netdev
[Top] [All Lists]

[no subject]

To: netdev@xxxxxxxxxxx
From: Kai Germaschewski <kai@xxxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 16 Mar 2000 10:13:42 +0100 (CET)
Sender: owner-netdev@xxxxxxxxxxx
Hey there!

Trying to clean up the current ISDN net interface code for 2.4,
I'm facing the following problem.

Basically, the structure is the following:

There's the so called ISDN link layer (LL), which interfaces to the
network layer as a struct net_device and also interface to HL (hardware
layer) - drivers that provide actual channels to transfer data on.

The problem is flow control and locking the xmit path. Basically, it
should easily work the following way:

isdn_net_hard_start_xmit()
{
        frame data accordingly (e.g. syncppp, ciscohdlc or whatever)
        send data to HL channel.
}       

In this setup, the network layer guarantees that hard_start_xmit() is
called single threaded, and therefore the HL driver send routine as well.

Now, we also have to send supervisory frames sometimes, e.g. negotiation
frames which are send from userspace (ipppd), or timer (keep-alive
packets), compression reset frames,...

Basically I can see two ways to ensure that send_data_to_HL is called
single threaded:

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.

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().

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.


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?

Thanks,
Kai


<Prev in Thread] Current Thread [Next in Thread>
  • [no subject], Kai Germaschewski <=