|
osdir.com mailing list archive |
|
Subject: Re: Re: Lwip UDP performance - msg#00089List: network.lwip.general> > Ahum, good to learn this. > The shiny Altera sales talks won't tell these nasty problems. Come on, now. When have sales talks ever told that the product being sold would be anything else than glisteningly excellent and devoid of any problems whatsoever ;). Oh, and better than competition with at least factor of three. Thread at a glance:
Previous Message by Date: click to view message previewuse of pbuf_queue() at interrupt levelHi all, I am interfacing the lwIP stack with an FPGA implementation that is capable of tx/rx of eth frames. I am looking for some tips from you guys please. The rx can be interrupt driven or polled. I would like to use rx interrupts to queue up rx'd frames and exit the isr. Then in background loop, the rx queue can be processed and all packets q'd up can be fed to the stack. There is no RTOS in this system, just a main (background) loop with foreground interrupts. So this means raw API with both SYS_LIGHTWEIGHT_PROT and NO_SYS set to 1. I would like to use the existing pbuf_queue and _dequeue mechanism to q incoming packets under interrupt. This means that I need to call pbuf_alloc( PBUF_RAW, FPGA_RX_BUFFSIZE, PBUF_POOL ) and pbuf_queue( rxQ, p ) from the rx isr. This in turn means that in the main loop when the rx q is read, I would have to disable FPGA rx interrupts during the call to pbuf_dequeue() (pbuf_alloc() is already taken care of with SYS_ARCH_PROTECT/UNPROTECT mechanism and SYS_LIGHTWEIGHT_PROT enabled). So my questions are: - Is my rx netif design ok for lwIP? - If so, why aren't pbuf_queue() and pbuf_dequeue() already protected with SYS_ARCH_PROTECT/UNPROTECT ? Best regards and thanks for an excellent stack!!! John Disclaimer: This message is intended for the use of the individual(s) or entity named above. It may contain information which is privileged or confidential. If you are not the intended recipient, please return it to sender as soon as possible and be aware that any disclosure, copying, distribution or use of its contents is prohibited. The views expressed in this communication may not necessarily be the views held by the company. Next Message by Date: click to view message previewRe: Re: Lwip UDP performanceAtte wrote: > Come on, now. When have sales talks ever told that the product being sold > would be anything else than glisteningly excellent and devoid of anyproblems > whatsoever ;). Oh, and better than competition with at least factor of three. We're a big Altera fan, without any cynism. Their Quartus design software is great :-) compared to the problematic Xilinx tools :-(. The only problem I have with their current NIOS offering is that it can be good for a few DSP like apps, but I don't see it as replacement for let's say a Coldfire or ARM9 with embedded MACs (a 'network processor'). When hearing the MAC isn't so good, or very constrained, I'm glad someone else confirms this idea. I guess the limited buffering has something todo with souping up many M4Ks (FPGA memory cells) otherwise. Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv Previous Message by Thread: click to view message previewRe: Re: Lwip UDP performancelwip-users-bounces+christiaan.simons=axon.tv-qX2TKyscuCcdnm+yROfE0A@xxxxxxxxxxxxxxxx wrote on 28-03-2006 12:12:27: > I'm using this ethernet hardware too and its sad but true, the > device does only have 4 fixed size (receive) buffers. Ahum, good to learn this. The shiny Altera sales talks won't tell these nasty problems. > Routing packets thought the stack will take much more time than, but > if u have send-delays, u can process the packets from a buffer after > the bursts. Do you have an idea where lwIP spends a lot of time in your system? If you do know about weak points in lwIP I can have a look at those. I think the pbuf_alloc() can be a bit expensive, and when having a lot of netifs and PCBs it can slow things down. The memcpy's in ip_reass won't help much either. For unfragmented traffic I don't expect any big delays. Currently I can't pin-point truly encumbered code with regards to unfragmented IP/UDP speed. Speeding up the lwIP core for reading unwanted broadcast UDP (Microsoft SMB blabla) is a bit of a priority for us. (I don't want to disable the UDP checksumming, it's only done for traffic that is accepted anyway) Bye, Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv Next Message by Thread: click to view message previewRe: Re: Lwip UDP performanceAtte wrote: > Come on, now. When have sales talks ever told that the product being sold > would be anything else than glisteningly excellent and devoid of anyproblems > whatsoever ;). Oh, and better than competition with at least factor of three. We're a big Altera fan, without any cynism. Their Quartus design software is great :-) compared to the problematic Xilinx tools :-(. The only problem I have with their current NIOS offering is that it can be good for a few DSP like apps, but I don't see it as replacement for let's say a Coldfire or ARM9 with embedded MACs (a 'network processor'). When hearing the MAC isn't so good, or very constrained, I'm glad someone else confirms this idea. I guess the limited buffering has something todo with souping up many M4Ks (FPGA memory cells) otherwise. Christiaan Simons Hardware Designer Axon Digital Design http://www.axon.tv Loading Comments...
|
|
