Re: [lwip-users] LWIP PPP - When connecting, int sifup(ppp_pcb *pcb) is called multiple times

[Sylvain Rochet]

Hi Brian,


On Fri, Oct 30, 2015 at 09:42:26AM -0400, Brian Stull wrote:
> Thank you Sylvain.
> 
> I'm not sure I'm comfortable with LWIP to make the changes that you 
> mentioned but I'll look at it more closely.
> 
> With the current implementation, if I wait in the sio_write() function 
> until the data is transmitted, this is going to hold up the LWIP stack 
> (which I'm guessing is not good).
> 
> Let me explain my current implementation of sio_write() and you can 
> tell me if it seems wrong. I have concerns with holding up LWIP but I 
> don't see an easy way around it. No matter how many buffers I have 
> LWIP could eventually fill them up I would think... then what should 
> happen?

In this case the whole stack must wait because you should prevent 
anything to create more packets.

And what if there is a fast Ethernet netif + a slow PPPoS netif ?  We 
just don't support that properly, if the PPPoS interface is currently TX 
bound, then the whole stack will be slowed down at the PPPoS interface 
throughput, that's it.

There is still one way to improve that, by doing an aggressive packet 
drop at the PPPoS serial level. We could pass a pbuf of a complete 
packet instead of a buffer in the PPPoS output callback function, this 
way we would be able to drop a whole packet safely and let TCP deal with 
that. That's an acceptable outcome to mitigate this issue for me.

Thinking about what I said yesterday, I'm not sure the serial retry 
should be on the lwIP side, today I have the feeling that's actually a 
low level driver detail. Especially if we pass pbuf, you can hold them 
in your driver until you are able to send them.


> My current sio_write() implementation:
> 
> 1. I have a dedicated buffer to send sio serial data from.
> 2. When sio_write() is called, I check to see if the UART is available 
>    to send.
> 3. If the UART is available, I'm copying the data into my dedicated 
>    buffer and starting the UART write. I then return "len"
> 4. If the UART is NOT available, I'm waiting until it is free then I'm 
>    going back to step #3.
> 
> So, basically, I can queue up one sio_write packet then I start having 
> to wait...

Yes, that's fine, or even if it's not that fine, that's how it is 
currently (mis)designed ;-)


Sylvain

signature.asc
Description: Digital signature