netdev - RE: [PATCH net-next] loopback: sctp: add NETIF_F_SCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6C96DE@AcuExch.aculab.com>
Date:	Mon, 24 Feb 2014 10:17:58 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Daniel Borkmann' <dborkman@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCH net-next] loopback: sctp: add NETIF_F_SCTP_CSUM to
 device features

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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html