Re: [lwip-users] Expected behavior of linkoutput()?

[Sylvain Rochet]

Hi,

On Wed, Jan 12, 2022 at 04:39:30PM -0000, Grant Edwards wrote:
> What is the expected behavior of the netif linkoutput() function?
> 
> Specificallyy, is it expected to
> 
>  1) Block until the packet has been sent?
> 
> or
> 
>  2) Place the packet in a TX queue/fifo and return immediately?
> 
> All of the Ethernet drivers I've worked on for other RTOSes in the
> past couple decades expected 2), since the output function might be
> called from a context that can not block. If the tx fifo/queue was
> full, an error was returned. In either case the output function always
> returned immediately.
> 
> I'm currently looking at a blob of code that acts both as an Ethernet
> driver for lwIP as well as implements a set of industrial protocols
> "under the covers" without lwIP being aware of that traffic. The plan
> is to remove the industrial protocl stuff and convert it into a
> "normal" lwIP driver.
> 
> That blob of code does 1) above. There is no TX packet queue/fifo at
> all. the linkoutput() function copies the frame into the MAC, starts
> transmission, and then blocks until transmission is complete. That
> means that linkoutput must always be called from a normal OS thread
> context.
> 
> Is this blocking, non-queueing approach the normal way implement
> linkoutput() for lwIP?

Actually, it should do both. Place the packet in the TX queue and return 
immediately, BUT if the queue is full it should wait for a free slot.

Sylvain

signature.asc
Description: Digital signature