lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] R: socket slow down


From: Rastislav Uhrin
Subject: [lwip-users] R: socket slow down
Date: Fri, 20 May 2016 14:27:30 +0200

Hello Jens,

 

I am still on this problem.

 

Yes. I have interrupt and I have semaphore. See bellow…

 

But what can be wrong?  How do I detect that packets are behind?

 

Thanks a lot

 

Rastislav

 

 

Interrupt

void ETH0_0_IRQHandler(void)

{

  uint32_t status;

 

  status = XMC_ETH_MAC_GetEventStatus(&eth_mac);

 

  if (status & XMC_ETH_MAC_EVENT_RECEIVE)

  {

    sys_sem_signal_isr(&eth_rx_semaphore);

  }

 

  XMC_ETH_MAC_ClearEventStatus(&eth_mac, status);

 

}

 

Task waiting on semaphore

static void

ethernetif_input(void *arg)

{

  struct pbuf *p = NULL;

  struct eth_hdr *ethhdr;

  struct netif *netif = (struct netif *)arg;

 

  while(1)

  {

    sys_arch_sem_wait(&eth_rx_semaphore, 0);

 

    p = low_level_input();

 

    if (p != NULL)

    {

                 ethhdr = p->payload;

                 switch (htons(ethhdr->type))

                 {

                   case ETHTYPE_IP:

                  case ETHTYPE_ARP:

                     /* full packet send to tcpip_thread to process */

          if (netif->input( p, netif) != ERR_OK)

          {

            pbuf_free(p);

          }

 

          break;

 

                   default:

                     pbuf_free(p);

                     break;

                 }

    }

  }

}

 

Input processing

static struct pbuf *

low_level_input(void)

{

  struct pbuf *p = NULL;

  struct pbuf *q;

  uint32_t len;

 

  len = XMC_ETH_MAC_GetRxFrameSize(&eth_mac);

 

#if ETH_PAD_SIZE

  len += ETH_PAD_SIZE;    /* allow room for Ethernet padding */

#endif

 

  if (len < XMC_ETH_MAC_BUF_SIZE)

  {

 

    /* We allocate a pbuf chain of pbufs from the pool. */

    p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);

 

    if (p != NULL)

    {

#if ETH_PAD_SIZE

      pbuf_header(p, -ETH_PAD_SIZE);  /* drop the padding word */

#endif

 

      XMC_ETH_MAC_ReadFrame(&eth_mac, buffer, len);

 

      len = 0;

      /* We iterate over the pbuf chain until we have read the entire

       * packet into the pbuf. */

      for (q = p; q != NULL; q = q->next)

      {

        /* Read enough bytes to fill this pbuf in the chain. The

         * available data in the pbuf is given by the q->len

         * variable.

         * This does not necessarily have to be a memcpy, you can also preallocate

         * pbufs for a DMA-enabled MAC and after receiving truncate it to the

         * actually received size. In this case, ensure the tot_len member of the

         * pbuf is the sum of the chained pbuf len members.

         */

         memcpy(q->payload, &buffer[len], q->len);

         len += q->len;

      }

 

#if ETH_PAD_SIZE

      pbuf_header(p, ETH_PAD_SIZE);    /* Reclaim the padding word */

#endif

 

    }

    else

    {

      XMC_ETH_MAC_ReadFrame(&eth_mac, NULL, 0);

    }

  }

  else

  {

    XMC_ETH_MAC_ReadFrame(&eth_mac, NULL, 0);

  }

 

  return p; 

}

 

-----Messaggio originale-----
Da: lwip-users [mailto:address@hidden Per conto di Jens Nielsen
Inviato: mercoledì 11 maggio 2016 16:52
A: address@hidden
Oggetto: Re: [lwip-users] socket slow down

 

Hi

 

If you search the list you will find a lot of people with the same question, it's impossible to tell where your packets are delayed without you doing some analysis (traces? breakpoints?) but one thing I can say for sure is that your problem is quite certainly not within lwip. A common error is to assume that one packet equals one interrupt which equals one signalled semaphore which equals one processed packet, whenever you receive a second packet before the previous is processed you'll be "one packet behind" and experience delays like you describe.

Where did you get your driver?

 

Best regards

Jens

 

 

On 2016-05-11 12:42, Rastislav Uhrin wrote:

> 

> Hello,

> 

> I need advice and help on one issue with lwip stack version 1.4.1. I

> am new to this stack and to networking in general. Nevertheless I have

> integrated it to application on Infineon xmc processor together with

> FreeRTOS.

> 

> Looking on many different examples on the internet and many trial and

> error. I am using netconn sockets. Application works!

> 

> The only problem is that after some time, better say after exchanging

> several 10-100 packets of different sizes, response gets slow. From

> 2ms down to 2-3seconds. It still works but slow. Same if I use ping.

> 

> I tried all possible setting of lwip options but of course since I

> don’t have deep insight of what they influence I was not able to

> improve this behavior.

> 

> I would appreciate if you can give me a hint what could be wrong, what

> could I check, how to proceed to debug this strange behavior.

> 

> I tried also new version 2.0 of stack but behavior is same.

> 

> rum

> 

> 

> 

> _______________________________________________

> lwip-users mailing list

> address@hidden

> https://lists.nongnu.org/mailman/listinfo/lwip-users

 

 

_______________________________________________

lwip-users mailing list

address@hidden

https://lists.nongnu.org/mailman/listinfo/lwip-users


reply via email to

[Prev in Thread] Current Thread [Next in Thread]