I would agree with Sylvain.
If we introduce something that will make lwip drop packets and let higher protocols to handle that then it might be ok with TCP, but with UDP and such it will not.
My point here is that solution needs to be in driver code or maybe in some configuration of lwip to handle slower hardware.
On Oct 30, 2015 6:18 PM, "Sylvain Rochet" <
address@hidden> wrote:
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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users