From: Daniel Borkmann > Drivers are allowed to set NETIF_F_SCTP_CSUM if they have > hardware crc32c checksumming support for the SCTP protocol. > Currently, NETIF_F_SCTP_CSUM flag is available in igb, > ixgbe, i40e/i40evf drivers and for vlan devices. > > If we don't have NETIF_F_SCTP_CSUM then crc32c is done > through CPU instructions, invoked from crypto layer, or > if not available as slow-path fallback in software. > > Currently, loopback device propagates checksum offloading > feature flags in dev->features, but is missing SCTP checksum > offloading. Therefore, account for NETIF_F_SCTP_CSUM as > well. > > Before patch: > > ./netperf_sctp -H 192.168.0.100 -t SCTP_STREAM_MANY > SCTP 1-TO-MANY STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.0.100 () port 0 AF_INET > Recv Send Send > Socket Socket Message Elapsed > Size Size Size Time Throughput > bytes bytes bytes secs. 10^6bits/sec > > 4194304 4194304 4096 10.00 4683.50 > > After patch: ... > 4194304 4194304 4096 10.00 15348.26 That seems a much larger increase than you'd expect from removing a software CRC of the data chunks. Are you sure that some other difference in the data flows wasn't also triggered. I'm also not sure that 4096 is a representative message size for SCTP. I'm not sure what else it is used for, but SCTP is used to carry various SS7 protocols and interfaces over IP (SIGTRAN: eg M3UA). For SS7 the maximum message size is around 270 bytes, and the average size nearer 100. It is also difficult to model, but the typical traffic for SS7 is neither bulk data, nor command-response. Rather it is single packets (maybe received from one of many 64k links) that need transmitting within a reasonable time interval, a delay of 1-2ms might be acceptable. This basically means that Nagle has to be disabled (because you never want the 'timeout waiting for an ack') and almost every data chunk ends up in its own (short) ethernet frame. David -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
