Re: How much RAM needed for low end Ethernet application?

From: Adam Dunkels (adam_at_sics.nospam.se)
Date: 03/02/05 

Date: Wed, 02 Mar 2005 19:36:45 +0000

On Wed, 02 Mar 2005 09:53:24 -0700, Richard H. wrote:

> Adam Dunkels wrote:
>> the fact that the Ethernet controller had buffer memory.
>
> Yes, often more than the MCU. While I wouldn't leap to use it as
> general-purpose storage, it seems a convenient resource for packet
> construction, and avoids the need to transfer it in a subsequent step.

How many Ethernet controllers are able to address this memory directly?
I wrote a device driver for the CS8900a and I seem to remember that it
only provided a sequential interface to its packet buffer (i.e., read and
write bytes from the start of the packet to the end, no "random" access).
 
>> Do you mean storing connection state inside the Ethernet controller's
>> memory? I guess it would be quite possible to do so, although there
>> would be a performance hit with every incoming packet since the list of
>> connections would have to be scanned to check which connection that
>> should receive the packet.
>
> Ick. That's a bit more aggressive than I was thinking, but it's an
> interesting thought for extremely limited systems.
>
> No, I'm actually thinking along the lines of keeping only the essential
> variables in SRAM per-session and building the rest on-the-fly as the
> header is being written to the NIC. Off-the-cuff... remote IP & port,
> session sequence & ack numbers, header flags, session MSS & window size,
> add up to ~17 bytes per TCP session. (And of course, the ARP table,
> which ideally has just the default gateway instead of many same-subnet
> peers.)

Hmmm, maybe I don't get it, but aren't you placing the entire TCP
connection state in the Ethernet controller's SRAM then?

>> Yes, definitely. Adding the ability to have multiple outstanding TCP
>> segments does however complicate both the sending code and the ACK
>> processing code, and would lead to both increased code size and
>> slightly increased RAM requirements (since more state needs to be
>> kept).
>
> Yes. ISTR that Bentham had an interesting approach for handling static
> data in TCP/IP Lean, where certain info was either stored in the session
> table or through trickery in the Sequence numbering that pointed to the
> "file" object and offset, allowing retransmissions to be re-built
> as-needed from the static source data instead of buffering. (Workable
> only where data can be trivially reconstructed from the source.)

Yes, that is a nice trick and saves four bytes of per-connection state.
However, if I remember correctly, his stack did not do retransmissions but
relied on the remote host to do retransmissions. This actually works in
some situations, where both hosts are sending data simultaneously (like an
HTTP GET / response situation) but does not work for unidirectional
transfers.

> This would seem to support large windowing with no re-TX buffering
> (i.e., max throughput on high-latency links with little resource
> overhead on the device)

Hmmm, I don't think it can be extended *that* easily. One problem arises
when doing retransmissions: there is no way of knowing what sequence
number to retransmit. Unless you store it in RAM, but that sort of defeats
the purpose of the trick :-)

Regards,

/adam 

-- 
Adam Dunkels, Swedish Institute of Computer Science
http://www.sics.se/~adam/, <adam@sics.nospam.se>

Relevant Pages

  • Re: Library design for downloading an unknown amount of data?
    ... Multiple manufacturers just adds to the fun! ... Some devices send everything in a single packet, ... you could malloc the correct sized buffer. ... devices that only have 32KB of memory. ...
    (comp.lang.c)
  • Re: Library design for downloading an unknown amount of data?
    ... A potential problem with this approach is that the buffer size will be ... Some devices send everything in a single packet, ... In some protocols it is simply fixed, and for others you can choose it yourself, but you should use the maximum allowable size for maximum speed. ... Right now the device with the highest memory capacity has 2MB of memory. ...
    (comp.lang.c)
  • CONFIG_PACKET_MMAP revisited
    ... I've been looking into faster ways to do packet captures and I stumbled on ... In that discussion Jamie Lokier suggested having a memory buffer that's ... shared between user and kernel space and having the NIC do DMA transfers ...
    (Linux-Kernel)
  • Re: Question about NDIS memory management
    ... Thanks for the reply Stephan - in my original message when I said "NDIS ... nor the memory that make up the ... actual buffer area. ... When the memory is full a new packet and buffer are ...
    (microsoft.public.development.device.drivers)
  • ethernet interrupts
    ... 07:04.0 Ethernet controller: Intel Corporation 82546GB Gigabit ... Subsystem: Samsung Electronics Co Ltd: Unknown device d001 ... Memory at fe9e0000 ... Capabilities: ...
    (comp.os.linux.development.system)