netdev - [PATCH net-next 0/8] net: Checksum offload changes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.2.02.1408251738030.5516@tomh.mtv.corp.google.com>
Date:	Mon, 25 Aug 2014 17:55:46 -0700 (PDT)
From:	Tom Herbert <therbert@...gle.com>
To:	davem@...emloft.net, netdev@...r.kernel.org
Subject: [PATCH net-next 0/8] net: Checksum offload changes - Part VI

I am working on overhauling RX checksum offload. Goals of this effort
are:

- Specify what exactly it means when driver returns CHECKSUM_UNNECESSARY
- Preserve CHECKSUM_COMPLETE through encapsulation layers
- Don't do skb_checksum more than once per packet
- Unify GRO and non-GRO csum verification as much as possible
- Unify the checksum functions (checksum_init)
- Simplify code

What is in this sixth patch set:

- Clarify the specific requirements of devices returning
  CHECKSUM_UNNECESSARY (comments in skbuff.h).
- Add csum_level field to skbuff. This is used to express how
  many checksums are covered by CHECKSUM_UNNECESSARY (stores n - 1).
- Change __skb_checksum_validate_needed to "consume" each checksum
  as indicated by csum_level as layers of the the packet are parsed.
- Remove skb_pop_rcv_encapsulation, no longer needed in the new
  csum_level model.
- Allow GRO path to "consume" checksums provided in CHECKSUM_UNNECESSARY
  and to report new verfiied checksums for use in normal path fallback.
- Add proper support to SCTP to accept CHECKSUM_UNNECESSARY to validate
  header CRC.
- Modify drivers to set skb->csum_level instead of setting
  skb->encapsulation to indicate validation of an encapsulated
  checksum on receive.

Please review carefully and test if possible, mucking with basic
checksum functions is always a little precarious :-)

----

Test results with this patch set are below. I did not see any
obvious performace regression.

Tests run:
   TCP_STREAM: super_netperf with 200 streams
   TCP_RR: super_netperf with 200 streams and -r 1,1

Device bnx2x (10Gbps):
   No GRE RSS hash (RX interrupts occur on one core)
   UDP RSS port hashing enabled.

* GRE with checksum with IPv4 encapsulated packets
  With fix:
    TCP_STREAM
        12.77% CPU utilization
        9341.93 Mbps
    TCP_RR
        91.33% CPU utilization
        157/235/391 90/95/99% latencies
        1.17991e+06 tps
  Without fix:
    TCP_STREAM
        12.45% CPU utilization
        9329.12 Mbps
    TCP_RR
        90.49% CPU utilization
        154/227/361 90/95/99% latencies
        1.17893e+06 tps

* GRE without checksum with IPv4 encapsulated packets
  With fix:
    TCP_STREAM
        17.64% CPU utilization
        9316.63 Mbps
    TCP_RR
        90.67% CPU utilization
        158/233/372 90/95/99% latencies
        1.17627e+06 tps
  Without fix:
    TCP_STREAM
        18.2% CPU utilization
        9227.35 Mbps
    TCP_RR
        89.73% CPU utilization
        154/222/343 90/95/99% latencies
        1.17868e+06 tps

* VXLAN with checksum
  With fix:
    TCP_STREAM
        20.94% CPU utilization
        9094.15 Mbps
    TCP_RR
        94.48% CPU utilization
        153/248/462 90/95/99% latencies
        1.18033e+06 tps
  Without fix:
    TCP_STREAM
        20.75% CPU utilization
        9093.67 Mbps
    TCP_RR
        94.78% CPU utilization
        149/239/441 90/95/99% latencies
        1.19141e+06 tps

* VXLAN without checksum
  With fix:
    TCP_STREAM
        25.13% CPU utilization
        9081.43 Mbps
    TCP_RR
        95.04% CPU utilization
        153/238/428 90/95/99% latencies
        1.16169e+06 tps
  Without fix:
    TCP_STREAM
        23.82% CPU utilization
        9085.64 Mbps
    TCP_RR
        93.91% CPU utilization
        156/248/458 90/95/99% latencies
        1.17247e+06 Mbps
--
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