Altera TSE driver and example program for lwIP (1.3.2)

Bill,

--- Quote Start ---

First, pbuf payload is guaranteed aligned. I use custom version of this driver (more optimized and improves on SGDMA and PHY handling plus some bug fixes in the Altera code) and took out the alignment check and added an assertion and it never asserts. If user code sets payload (a bad practice) than it's not guaranteed, but pbuf_alloc aligns payload.

--- Quote End ---

As we discovered all together under some circumstances innocent tcp_write(pcb, long_help_message, len, NOCOPY) can have an effect of “user code setting payload”. How could I expect this in advance?

--- Quote Start ---

An application that uses UDP for high data rates is probably using a custom client in which case the payload size could be enforced. I use a zero-copy UDP high speed reliable protocol (the hardware writes in the UDP payload and checksum) and in this case the payload is large and always aligned.

--- Quote End ---

Yes, for UDP alignment is under developer’s control. I also had to reinvent some kind of “zero-copy reliable UDP”. I use LWIP for retransmitting only – this makes life easier. Actually, if you cook UDP packets in hardware, you can retransmit a packet without LWIP intervention at all – just instruct one SGDMA to ship out exactly what had been delivered into memory by another SGDMA.

--- Quote Start ---

You only need to unwind if pkt->next isn't NULL. An unchained pbuf can never have a payload size less then 4 because of the IP header. I'd put back the pkt->next != NULL test before the for loop.

--- Quote End ---

Agree.

--- Quote Start ---

Minor:

       // Unwind pbuf chains 
       if (pkt->tot_len > sizeof(buf2)) {            // no space for unwinding; drop the packet            
              return ERR_OK;        }

Can't occur. lwIP will never chain more than the MTU. It can't because 802.11 cannot support it.

--- Quote End ---

Would be better to turn into ASSERT. (For those who like building pbufs by hand, like me :) ).

--- Quote Start ---

This bug in the SGDMA (it's a bug if you can't sent 1-x bytes) maybe why InterNiche is so slow and full of copies. It's too bad it cripples lwIP which otherwise is much more efficient.

I wonder if we can write the small payload bytes right to the MAC. I.e. don't use SGDMA but use a for loop to write 1 to 3 bytes to the MAC buffer (same place the SGDMA writes to)? Does either of you or anyone know if this could be done? I think I'll put in a service request for this as a SGDMA bug.

--- Quote End ---

If you only need to insert 1-3 bytes at the _end_ of packet, you may try standard “On-Chip FIFO Memory Core” (or very simple custom component) and mux its output with the SGDMA (though I never implemented this in hardware). I don’t know readily available solution for general case (when incomplete words are inside the packet). Should not be very difficult to code. The main challenge seems to be repacking of the stream to become Avalon-ST complaint: e.g. <sop4><4><1><4><2eop> into <sop4><4><4><3eop>.

--- Quote Start ---

Great discussion - thanks!

--- Quote End ---

Thank you also!