|
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(ð_mac); if (status & XMC_ETH_MAC_EVENT_RECEIVE) { sys_sem_signal_isr(ð_rx_semaphore); } XMC_ETH_MAC_ClearEventStatus(ð_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(ð_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(ð_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(ð_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(ð_mac, NULL, 0); } } else { XMC_ETH_MAC_ReadFrame(ð_mac, NULL, 0); } return p; } -----Messaggio originale----- 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 > https://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list |
[Prev in Thread] | Current Thread | [Next in Thread] |