linux-atm-general

[Linux-ATM-General] stop_queue for ATM?

[Nathan W. <na...@tr...>]

Hi,

Is there any mechanism for an ATM driver to tell the kernel that its TX
queue is full?  I'd like to keep solos-pci's TX queue short so traffic
priorities can be managed in the kernel.

I think network devices can use netif_stop_queue(), so I'm wondering if
there's something similar for ATM devices.

Regards,
Nathan

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

[Karl H. <ka...@hi...>]

  On 20/08/2010 3:12, Nathan Williams wrote:
> Hi,
>
> Is there any mechanism for an ATM driver to tell the kernel that its TX
> queue is full?  I'd like to keep solos-pci's TX queue short so traffic
> priorities can be managed in the kernel.
>
> I think network devices can use netif_stop_queue(), so I'm wondering if
> there's something similar for ATM devices.
>
AFIK it's not currently possible inside device drivers.   Currently it's 
done where we have a netdevice,  see the clip and br2684 modules.  With 
br2684ctl you can adjust the sndbuff to change when netif_stop_queue() 
is called.


Two issues i have now are:
1.  There is no way for the device driver to stop the queue.

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


--
Karl

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.

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

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

On Fri, 20 Aug 2010 11:12:44 +1000
Nathan Williams <na...@tr...> wrote:
> Hi,
> 
> Is there any mechanism for an ATM driver to tell the kernel that its
> TX queue is full?  I'd like to keep solos-pci's TX queue short so
> traffic priorities can be managed in the kernel.
> 
> I think network devices can use netif_stop_queue(), so I'm wondering
> if there's something similar for ATM devices.

i suspect this doesnt work the way you think it does.  the .send
routine does return a value to indicate if it was successful in
scheduling the data to be transmitted.  however, it is up the layer to
actually do something if the send fails.  using lec as an example, if
the send fails, it calls a netif_stop_queue() to pause sending for a
little while.  this generally causes whatever protocol is running over
the network interface to handle this packet loss/stoppage as congestion
and backoff in someway.

i suppose if we were considering rewriting the interface, the atm tx
layer could use some sort of callback provided by the next layer to
ask the layer to stop sending.  then the driver writer would need to
handle calling some sort of resume when the hardware is ready to send
again.

what layer are you using to talk to the solos-pci tx queue? some of the
layers in the atm stack ignore the .send return code still.

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

[Nathan W. <na...@tr...>]

On Fri, 2010-08-20 at 09:25 -0400, chas williams - CONTRACTOR wrote:
> what layer are you using to talk to the solos-pci tx queue? some of the
> layers in the atm stack ignore the .send return code still.

I'm using pppoatm for PPPoA and br2684 for PPPoE.