[asterisk-bugs] [JIRA] (DAHLIN-329) Support multiple dynamic spans with FIFO

[Pavel Selivanov (JIRA)]

    [ https://issues.asterisk.org/jira/browse/DAHLIN-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=212476#comment-212476 ] 

Pavel Selivanov commented on DAHLIN-329:
----------------------------------------

Gentlemen, please forgive me, being extremely busy.

Please, take a look at the patch.
Hope you'll like it.

I've took my latest patches dahdi_dynamic.c.patch and integrates patches from Michael.
Feel free to change credit.

1. Injected anti-flood by Michael.
2. Reworked tasklet scenario (describe later)
3. Fixed a bit txcnt incrementing.
4. Prepared a STUB to implement rx tasklet for every dynamic SPAN.

As I wrote, it's not the question, will we use tasklet in dynamic.
The question is - where.
We MUST call dev_queue_xmit with interrupt enabled.

So, ENABLE_TASKLET is useless, and absolutely wrong word.
So, I removed all the code #if ENABLE_TASKLETS.

modprobe rxtasklet=0
TDMoE data will be processed(echocancelled) in interrupt context.
All TX will be done in tasklet.
Thus, data can be processed on different CPU cores.

modprobe rxtasklet=1 (default)
TDMoE data will be processed(echocancelled) in tasklet
All TX will be done in tasklet, so, all SPANS will be processed in one tasklet on one CPU core.
All TX will be done (indirectly) in tasklet.

TODO: improve rxtasklet=1, by creating rx tasklet.
So, every SPAN will be processed in separate tasklet.
If the card is good - every new packet will come from another CPU core, so, tasklet will be started on another core.

                
> Support multiple dynamic spans with FIFO
> ----------------------------------------
>
>                 Key: DAHLIN-329
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-329
>             Project: DAHDI-Linux
>          Issue Type: Improvement
>      Security Level: None
>          Components: dahdi (the module), dahdi_dynamic
>    Affects Versions: 2.7.0
>         Environment: Kernel versions 2.6.24, 2.6.38 and 3.2.0 tested
>            Reporter: Michael Walton
>            Assignee: Russ Meyerriecks
>         Attachments: 2013.12.04_pavel_dahdi_dynamic.c.patch, dahdi-base.c.patch, dahdi_dummy.c.patch, dahdi_dynamic.c.patch, dahdi-dynamic-multispan-fifo.patch, kernel.h.patch
>
>
> The dynamic span driver works for one span, but is unable to handle the phase differences caused by line and network jitter and clock drift in a multiple span situation. The introduction of a configurable receive FIFO,  proper master clock priority switching and slip/skip processing solves this problem. Additionally, to support configurations where no telephony hardware is present, the highres timer from (defunct) dahdi_dummy is re-introduced into dahdi base to replace the core timer functionality (which is limited to 250Hz) with a true 1000Hz tick. As with the core timer, this is the fallback timing when no span provides master timing.
> Dynamic multispan introduces:
>  * Configurable fifo on incoming dynamic frames
>  * Master/slave dynamic spans with priority switching based on alarm status
>  * All transmit and receive processing is done in the dahdi_dynamic_run tasklet to ensure proper handling of jitter and phase differences
>  * Unreachable spans (RED alarm) switch to a poll mode to prevent network being flooded by 1ms frames that go nowhere
>  * Slip/skip statistics per span available on /proc/dahdi/dahdi_dynamic_stats
>  * High res timer added to dahdi-base to replace core timer with true 1ms tick timer
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira