Re: [lwip-users] Confused - Should I loop on pbufs in my receive callback?

[address@hidden]

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