|
From: | Sebastian Gonzalez |
Subject: | Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL |
Date: | Tue, 28 May 2013 09:42:22 -0700 (PDT) |
Hello Sebastian,
The example AT91 port from FreeRTOS has some issues that show up in
large traffic scenarios, typically with many UDP broadcasts or
multicasts, but could also be caused by high volume TCP.
I have optimized the driver in many ways so I don't remember exactly
the changes I made to fix this, but it was something like this:
- When pbufs are allocated in ethernetif.c, there are some conditions
where the packets aren't freed properly (if not an IP packet?). this led
to a memory leak.
- Sometimes there are not enough memp messages to pass packets/messages
to the tcpip thread. I increased this from 6? to 20.
There is also sometimes some unexpected behaviors from the AT91 EMAC
when receiving packets really fast, so for example if you are in the IRQ
for sending and then you receive something during, you need to take
care. My ISR looks like this:
void vEMACISR_Handler( void )
{
volatile unsigned portLONG ulIntStatus __attribute__ ((unused));
volatile unsigned portLONG ulTxStatus;
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;
/* Find the cause of the interrupt, cleared on read. */
ulIntStatus = AT91C_BASE_EMAC->EMAC_ISR;
if ( AT91C_BASE_EMAC->EMAC_RSR & AT91C_EMAC_REC )
{
/* A frame has been received, signal the lwIP task so it can
process
the Rx descriptors. */
AT91C_BASE_EMAC->EMAC_RSR = AT91C_EMAC_REC;
xSemaphoreGiveFromISR( xSemaphore, &xHigherPriorityTaskWoken );
}
ulTxStatus = AT91C_BASE_EMAC->EMAC_TSR;
if( ulTxStatus & AT91C_EMAC_COMP )
{
/* A frame has been transmitted. Mark all the buffers used by
the
frame just transmitted as free again. */
AT91C_BASE_EMAC->EMAC_TSR = AT91C_EMAC_COMP;
vClearEMACTxBuffer();
}
if( ulTxStatus & (AT91C_EMAC_UND | AT91C_EMAC_BEX))
{
/* A frame Tx failed. Reset Tx buffers. */
AT91C_BASE_EMAC->EMAC_TSR = AT91C_EMAC_UND | AT91C_EMAC_BEX;
EMAC_Statistics.tx_errors++;
vResetEMACTxBuffer();
}
/* Clear the interrupt. */
AT91C_BASE_AIC->AIC_EOICR = 0;
/* If a task was woken by either a frame being received then we may
need to
switch to another task. If the unblocked task was of higher
priority then
the interrupted task it will then execute immediately that the ISR
completes. */
if( xHigherPriorityTaskWoken )
{
portYIELD_FROM_ISR();
}
}
/*-----------------------------------------------------------*/
void vEMACISR_Wrapper( void )
{
/* Save the context of the interrupted task. */
portSAVE_CONTEXT();
/* Call the handler to do the work. This must be a separate
function to ensure the stack frame is set up correctly. */
vEMACISR_Handler();
/* Restore the context of whichever task will execute next. */
portRESTORE_CONTEXT();
}
I hope this helps. I've struggled a lot when moving from low-traffic
lab network to high-traffic production network.
Cheers
Ivan
> Date: Mon, 27 May 2013 10:01:44 -0700 (PDT)
> From: Sebastian Gonzalez <[hidden email]>
> To: [hidden email]
> Subject: [lwip-users] Receive path stuck due to pbuf_alloc returning
> NULL
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> I am using lwIP 1.3.2 with an Atmel AT91SAM7X512, and FreeRTOS. We
> have
> already used this combination in other projects with no problem, but
> now we
> using our design in a network with high density of UDP broadcast
> traffic
> causing the system to stop receiving.
> The transmission path keeps working as I can see ARP request messages
> coming
> out in the wireshark traces.
> After debugging and searching I found that several people had the same
> issue: The pbuf_alloc call from low_level_input in the ethernet driver
> returns NULL during the packet storm and keeps returning NULL, as if
> the
> TCP/IP task wasn't fast enough to free the pbufs, and thus the packets
> from
> the EMAC do not move to the upper layers.
> I do understand that during a packet storm all the packets that can't
> be
> processed are dropped, actually that's the behaviour that I expect.
> But I
> don't get why the consumer process is unable to free the packets that
> have
> already been passed to the upper layer.
> I have tried giving the TCP/IP thread the higher priority with no
> results.
> Also changed the number of pbufs from 8 to 16 and noticed that the
> problem
> happened later in time.
> Is there a recommended value for the number of pbufs, considering my
> reduced
> schema of memory?
>
> Best regards.
>
> Sebastian
>
>
>
>
> --
> View this message in context:
> http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461.html
> Sent from the lwip-users mailing list archive at Nabble.com.
>
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
If you reply to this email, your message will be added to the discussion below:http://lwip.100.n7.nabble.com/Receive-path-stuck-due-to-pbuf-alloc-returning-NULL-tp21461p21475.html
ADVERTENCIA
La información contenida en este correo electrónico, es
de carácter privado y confidencial, siendo para uso
exclusivo de su destinatario. Si usted no es el
destinatario correcto, o ha recibido esta comunicación
por error, le informamos que está totalmente prohibida
cualquier divulgación, distribución o reproducción de
esta comunicación según la legislación vigente y le
rogamos que nos lo notifique inmediatamente, procediendo
a su destrucción sin continuar su lectura.
Su dirección de correo electrónico, así como el resto de
los datos de carácter personal que nos facilite, podrían
ser objeto de tratamiento automatizado en nuestros
ficheros, con la finalidad de gestionar la agenda de
contactos de BY TECHDESIGN,S.L. Vd. podrá en cualquier
momento ejercer sus derechos de acceso, rectificación,
cancelación y oposición según la Ley Orgánica 15/1999
mediante notificación escrita a la siguiente dirección:
CALLE TOMAS EDISON 5 28500 ARGANDA DEL REY.
[Prev in Thread] | Current Thread | [Next in Thread] |