ColdFire/68K Microcontrollers and ProcessorsのトピックFEC Driver using Small Buffers?

FEC Driver using Small Buffers?

TomE — Mon, 02 Sep 2013 07:32:21 GMT

I'm working on a project where the usual small number of Ethernet FEC Receive Buffers just won't cut it. I'm getting data overruns.

In this project on an MCF5235, we're using the internal static RAM for both the Descriptor Ring and the buffers. That makes things a whole lot easier than having to worry about flushing the cache.

I can't use a lot of 1600-byte buffers as there's not enough SRAM. Fine, the FEC supports small buffers and will chain them for me. So I'm going to use 64 256-byte buffers. Small packets will take a single buffer and large ones might take six.

I'm looking for some example code that does this so I don't repeat the mistakes others have made.

Linux uses big buffers (where "big" means "will hold a full-size packet").

FNET uses big buffers.

Freescale's TCP/IP Lite (the Nichelite stack) has small and big buffers, but only uses big ones in the receive ring.

Does anyone know of any examples of a FEC driver that uses chained buffers?

Thanks,

TOm

Re: FEC Driver using Small Buffers?

scifi — Mon, 02 Sep 2013 19:28:09 GMT

I put together a lwip (OS-less mode) driver for the MCF52235 MCU a while ago. IIRC, its FEC is the same. I can't say it's seen a huge amount of testing, but it works in a number of always-on products with built-in web server and SNMP agent. I think I looked at Coldfire ethernet driver from eCos and got some ideas there. Feel free to use it as you wish.

Re: FEC Driver using Small Buffers?

TomE — Tue, 03 Sep 2013 13:18:54 GMT

Thank you. That code is simple and easy to understand.

Tom

Re: FEC Driver using Small Buffers?

TomE — Tue, 10 Sep 2013 13:38:11 GMT

The FEC driver was having problems due to:

1 - Only 8 receive buffers (other stacks use as few as 2),,

2 - A POLLED driver called from a polling loop to unload/free the buffers,

3 - A large company network with lots of devices using Avahi/Bonjour/Zeroconfig,

4 - The presence of some very large Bonjour/MDNS packets,

5 - That were taking up to 300ms to process in our device,

6 - That were delaying the polling loop and the Ethernet unload by 300ms.

So it was losing a lot of Ethernet packets. UDP packets, proving that the "U" in "UDP" can mean "Unreliable".

We got the MDNS processing down to 30ms, changed the buffers from 8 * 2k to 64 * 256 byte and now unload the ring under an interrupt into a pool of 150 buffers in main RAM, and it can take almost anything we can throw at it.

Can your TCP/IP stack take a Flood Ping with a preload of 80 and a count of 3000 on a 100MHz full-duplex Ethernet and not drop a single one? Before this change it would drop with a preload of less than 8.

Tom