xiaoxiang781216 commented on issue #6835: URL: https://github.com/apache/incubator-nuttx/issues/6835#issuecomment-1212725040
> > 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? > > Te be able to decode the eth_desc_s which contains extra information, such as packet type, timestamp, CRC, MAC filter, VLAN, Error only the MAC driver knows what this means. > > https://github.com/apache/incubator-nuttx/blob/5d12e350da31324e632ee7da3a3062b05212b74c/arch/arm/src/s32k3xx/hardware/s32k3xx_emac.h#L3076-L3082 > Yes, I understand that the MAC layer need additional descriptor before the IP packet. But, the process can directly handle in either irq handler and work callback before pass the data to TCP/IP stack. What I can't understand is why we need TCP/IP stack callback to netdev. > > 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 > > That API is to pass the data pointer to an Hardware CRC accelerator, in the case of the S32K3XX this doesn't work because the MAC itself has a build-in CRC checker that indicates that in the eth_desc_s IPCE mask when the packet has been received. > > ``` > #define EMAC_RDES1_IPCE_MASK (0x00000080u) /* IP Payload Error bit > * IP payload checksum (that is, the TCP, UDP, or ICMP checksum) > * calculated by the MAC does not match the corresponding checksum > * field in the received segment. */ > ``` > So, the hardware can check the checksum for receiving, but can't generate checksum for sending? In this case, we may need add new option to disable the checksum for one direction like CONFIG_NET_UDP_CHECKSUMS. > > 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 > > 1. The MTU of the specific interface determines the allocation size i.e. as shown in table above, Ethernet 1518, WIFI 576, CAN2.0B 13. > 2. Something like O1Heap solves the fragmentation, indeed at the expense of overhead but that's the trade-off > 3. See 1 Allocate the MTU of the interface, maybe add 4 bytes for a pointer to link them. > > There really not a 1 solution fits all, but I want to make sure though we've got something can easily be adapted to support all MAC controllers with DMA in NuttX. > Sure. another possible solution is to reuse IOB chain, so we can define a small IOB buffer size(the smallest MTU on the device) and link multiple IOB for the bigger MTU. > So if some authors of ethernet MAC drivers could share their thoughts if there's a compatible solution that can be used their driver. > > @davids5 @gregory-nutt @acassis -- 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]
