Honored Contributor
Honored ContributorBill,
--- Quote Start --- There may be a much faster way to handle these 1-3 byte SGDMA transfers. I believe it to be true that there would only be one 1-byte pbuf in a chain, is this true? If it *is* true, you could ensure that all pbufs are allocated with an extra 4 bytes of payload. This would be done for PBUF_POOL (not sure about PBUF_RAM). Take the 1 to 3 bytes of the next pbuf and add it to the end of the payload of the preceding one. Increase that len by 1 to 3 and set the second one to 0. Leave the chain in place but skip pbufs with len==0. This would be very efficient for the common case of a trailing short pbuf chain. --- Quote End --- May be, but not sure. I didn’t analyze TCP code in depth, but it looks like LWIP 1.4.0 tends to combine all writes, even NOCOPY ones, into single oversized buffer. That is why the driver usually sees a single “long” pbuf for single TCP packet. The notable exception I was “lucky” to trap into is a sequence of NOCOPY writes, issued in the moment when internal buffer is empty. In this state TCP allocates separate pbuf for the headers and chain it with the PBUF_REFs, pointing to user supplied data. --- Quote Start --- For PBUF_REF you may have to unwind to a new pbuf. Or ensure 0-copy doesn't use small payloads (probably not hard to manage). --- Quote End --- Surely this could be easily managed when one builds application from ground. But could be rather confusing when such things happen deep inside third-party code e.g. http server. Igor
