On Mon, Feb 1, 2021 at 5:14 AM Martin Schiller <ms@xxxxxxxxxx> wrote: > > But control frames are currently sent past the lapb write_queue. > So another queue would have to be created. > > And wouldn't it be better to have it in the hdlc_x25 driver, leaving > LAPB unaffected? Hmm.. Indeed. I agree. I also think the queue needs to be the qdisc queue, so that it'll be able to respond immediately to hardware drivers' netif_wake_queue call. Initially I was considering using the qdisc of the HDLC device to queue the outgoing L2 frames again (after their corresponding L3 packets having already gone through the queue). But Jakub didn't like the idea of queuing the same data twice. I also found that if an L3 packet was sent through the qdisc without being queued, and LAPB didn't queue it either, then the emitted L2 frame must be queued in the qdisc. This is both not optimal and causing problems when using the "noqueue" qdisc. Maybe the only way is to create a virtual device on top of the HDLC device, using the virtual device to queue L3 packets and using the actual HDLC device to queue L2 frames.
