Re: [lwip-users] TCP bandwidth limited by rate of ACKs

[address@hidden]

Mason wrote:
> > Well, given a correctly DMA-enabled driver, you could avoid one task
> > switch by checking RX packets from tcpip_thread instead of using another
> > thread for RX (as suggest your "Task breakdown" by the name "RxTask").
> Correct; the OS panics when I call tcpip_input from the ISR,
Hmm, tcpip_input uses sys_mbox_trypost() which should not wait until 
there's room in the mbox but instead return an error. On most OSes, 
there's a function that can be used here from an ISR (in contrast to a 
function usable from task level where a task can wait).
> I wanted to enable LWIP_TCPIP_CORE_LOCKING (and LWIP_TCPIP_CORE_LOCKING_INPUT;
> what is the difference? they're not documented AFAICS) but I was scared off by
> the "Don't use it if you're not an active lwIP project member" comment ;-)
Yeah well, it's work that hasn't been tested as much as the rest of the 
stack, I guess. However, it's been in there now long enough that it 
should be at least stable enough to use it for testing. I'd even use it 
for our products (if we used the API layer)...
> Also, my OS forbids using mutexes from an ISR.
Yes, you cannot used CORE_LOCKING from an ISR.
> Perhaps I could keep the RxTask, and enable LWIP_TCPIP_CORE_LOCKING_INPUT
> which would take tcpip_thread out of the equation? Thus, LOCK_TCPIP_CORE
> would be called from task context, which is fine.
I guess that would also be OK. Provided you would get DMA RX working, 
you'd then get off with 1 memcpy (to socket application buffers) and 2 
tasks switches (1 from ISR to RxThread, 1 from RxThread to application 
thread).

BTW, when using CORE_LOCKING and CORE_LOCKING_INPUT, the tcpip_thread 
mainly only serves timers and delayed writing of TCP data (if you write 
more to a socket than lwIP can buffer).
> > If I made the changes to support PBUF_REF for RX in git, would you be
> > able to switch to that for testing?
> Yes, I've tried to do a clean port, so I should be able to upgrade
> to a newer version quite easily.
I'll see what I can do :-)

Simon