Re: [Linux-ATM-General] stop_queue for ATM?

[chas w. - C. <ch...@cm...>]

On Fri, 20 Aug 2010 10:56:18 +0200
Karl Hiramoto <ka...@hi...> wrote:

> 2.  For example when there are multiple br2684 or clip VCs  on a
> device, if one VC has the device full the other VCs don't
> netif_stop_queue()

yeah that is a problem.  i had this when i implemented this flow
control for the lec driver.  so if one vc fills up you have to stop
sending on all the vc's since the network stack doesnt have a queue per
connection.

even so, most of the atm hardware has a single transmit schedule queue
and if this is full, no one should send.  your hardware might further
have some limit for a single vc.  so if you have a single vc per br2684
interface you should be fine.  but the problem might be getting fair
utilization across all those vc's.  you never know which one will
wakeup first.  the right answer might not be to wakeup as soon as one
could send again but when some real forward progress could be made.
br2684 uses:

static void br2684_pop(struct atm_vcc *vcc, struct sk_buff *skb)
{
...
        if (atm_may_send(vcc, 0))
                netif_wake_queue(net_dev);

that is a little agressive.  you might be able to send one packet, but
you might need to stop again.  atm_may_send() doesnt have idea of the
queue utilization in the atm hardware but if you use a value a bit
larger than 0 (like 1/2 of the wmem_alloc size) you might get better
results.