xiaoxiang781216 commented on issue #6835: URL: https://github.com/apache/incubator-nuttx/issues/6835#issuecomment-1212368582
Nice diagram! > PR #6834 is trying to address this, however on system with mixed interfaces utilizing the NET stack & IOB. For example > > Interface MTU > Ethernet 1518 > WIFI 576 > CAN2.0B 13 > When adding the DMA Descriptor to the IOB as proposed in #6834 each IOB in the case of IMXRT would by grow by 29bytes. > Before we can adjust IOB buffer size, let all netdev share a biggest header isn't a major concern. Also, the ratio of header space consumption is small if we compare it to the normal MTU size. Does it worth us to compilate the design(benefit is ~5% in most case). > I can think of some solutions but I'm not sure what would be best: > > 1. Make the IOB buffer peripheral specific, hence for the example above we will get 3 separate IOB buffer pools Yes, it's one solution but how about layer 2 forward(e.g. RNDIS<->Ethernet/WiFi/Modem) which is a feature we plan to add. To achieve the zero copy through the whole path, it require us to reserve the biggest header size and share the same allocator. > 2. Create a 2nd DMA aware IOB `iob_dma` that has metadata of the DMA descriptor and pheripheral. Where the Network stack can invoke callbacks to the pheripheral to parse the received metadata (also nice to check for HW offloading and then fallback to the SW method) The special handle can be achieved before netdev pass IOB to TCP/IP stack in receiving direction. The similar thing can be done in the transmit direction too, why we need callback here? > 3. Create IOB buffer pool that supports variable data length, a good example could be https://github.com/pavel-kirienko/o1heap > could be a solution, but we need consider that: 1. Since it is impossible to forecast the incoming packet size, we have allocate the full packet in the receiving side 2. Need consider the fragmentation problem and the house keeping overhead 3. How to accumulate the transmit data to form the full packet without reallocate/copy Another solution is make IOB buffer smaller than MTU(e.g. 256 instead 1518) and utilize the link list DMA in hardware. > Another thing I want to address is to support the HW offloading bits, there are ethernet MAC's that have IP offloading features such as checksum calculation done by MAC and simply indicate using a bit that the CRC in the DMA descriptor, or indicate that an automatic ARP response has been send. HW checksum is already supported, you can simply enable NET_ARCH_CHKSUM: https://github.com/apache/incubator-nuttx/blob/master/net/utils/Kconfig#L6-L26 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
