xiaoxiang781216 commented on PR #6834:
URL: https://github.com/apache/incubator-nuttx/pull/6834#issuecomment-1212265551

   > A Zero-copy ethernet solution would be indeed a great addition, when 
implementing a enet driver myself I noticed as well that packets are double 
stored and have a unnecessary copy action,
   
   The header and alignment is part of the offloading solution. The current 
design keep the old behavior as before, but give the implementation the 
possibility.
   
   > furthermore hw TCP/IP offloading (HW checksum etc) is also thing NuttX 
doesn't support that well.
   > 
   
   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
   
   > But wouldn't it be better to come up with a proposal to offload DMA 
directly into a IOB buffer and start a discussion (i.e. NuttX mailing list)
   
   It's better to show the code and 
   
   > how we can make this portable in such a way that it works all kinds of 
ethernet MAC's that have build-in DMA.
   
   The offload change is simple from the concept:
   
   1. TCP/IP stack pass IOB directly to netdev instead copy to d_buf
   2. netdev request the hardware send the data in IOB and free IOB to pool 
after done.
   3. The netdev allocate IOB and pass to hardware for receiving
   4. Pass IOB to ipv4_input/ipv6_input. TCP/IP stack will release the buffer 
after the data copy to the user buffer
   
   Of course, to keep compatibility, the new behavior need enabled by some flag.
   
   > I think this requires more changes into how IOB works but also the API of 
the NuttX Networking to work with these changes.
   
   Could you point out the detail change required for IOB? 


-- 
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: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to