Am 30.07.2019 um 03:37 schrieb lauziepi:
Hello,
I am seeing very slow response times from my device running lwip after
awhile. I have tried various settings as recommended here and elsewhere, and
the issue does not appear to be linked to an incorrect lwip configuration.
When searching around, I have seen a few people mentioning that the
interrupt can be raised when receiving a packet, but it does not guarantee
that only a single packet has been received (for example, a new packet could
be received before the interrupt is handled).
Below is my receive callback function. I have some custom error handling and
packet parsing / handling, but anyone familiar with lwip should recognize
the lwip function calls. Basically, my packets are supposed to match a
command, and the device running lwip is supposed to send a reply to the
"core" (a computer). Please note that I used example code provided by Xiling
as a starting point, as I am running lwip in a FPGA.
Here are 3 questions I have:
1 - Is it ok to reply to the packet directly in the receive callback? See
/errTcp = Eth_ControlPanel_SendPacket(&packet, tpcb);/ Would it be better to
raise a flag and send the response in my main loop?
By even sending the packet into lwIP directly in the RX interrupt,
you'll most probably get concurrency issues. Since I don't know the
function you mentioned, I cannot tell if that's ok.
2 - Am I supposed to add a loop somewhere in the receive callback to handle
the case where I can receive multiple packets before I can handle the
interrupt? I feel like I have more and more packets waiting in my queues,
and since I only read 1 packet each time I get an interrupt, this is why the
response time gets slower each time. What would be my looping conditions if
so?
Yes. One interrupt does *not* mean one packet. It means a trigger from
the hardware "there's something to do". If you get there too late, there
may be more than one packet. You certainly need to handle this.
3 - Does anything else appear wrong with this receive callback?
See inline below.
Thanks in advance, hopefully someone more experienced can shed some light on
this.
err_t ControlPanel_rcv_callback(void* arg, struct tcp_pcb *tpcb, struct
pbuf* p, err_t err)
{
if (!p) {
tcp_close(tpcb);
tcp_recv(tpcb, NULL);
return ERR_CONN;
Return ERR_OK here. This is a standard "FIN received".
}
tcp_recved(tpcb, p->len);
ParsedPacket packet;
bool hasBeenParsed = false;
u32 packetPayLoadSizePacket = p->len;
if((packetPayLoadSizePacket >= BASE_COMMAND_SIZE) &&
(packetPayLoadSizePacket <= (MAX_RX_DATA_RECEIVED_FROM_CORE +
BASE_COMMAND_SIZE)))
{
//xil_printf("Parsing packet received from core \n\r");
parseRxCmdFromCore(p->payload, &packet);
hasBeenParsed = true;
}
if(hasBeenParsed && (packet.packetSize == packetPayLoadSizePacket))
{
//xil_printf("The command from Core is now processed \n\r");
LabPETIICoreCmdProcessing(&packet);
}
else
{
//xil_printf("Error has been detected regarding packet size
\n\r");
packet.type = b_ERROR;
packet.data1 = e_BOARD_CMD_PACKETSIZE;
packet.errorFlag = b_ERROR;
packet.packetSize = BASE_COMMAND_SIZE;
}
pbuf_free(p);
buildResponsePacketForCore(&packet);
err_t errTcp;
errTcp = Eth_ControlPanel_SendPacket(&packet, tpcb);
tcp_close(tpcb);
return errTcp;
Return ERR_OK here. You handled the RX packet correctly. TX path is
something different.
Regards,
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
