[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Expected behavior of linkoutput()?
From: |
Grant Edwards |
Subject: |
[lwip-users] Expected behavior of linkoutput()? |
Date: |
Wed, 12 Jan 2022 16:39:30 -0000 (UTC) |
User-agent: |
slrn/1.0.3 (Linux) |
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?
Thanks,
--
Grant
- [lwip-users] Expected behavior of linkoutput()?,
Grant Edwards <=