1. 14 Jun, 2019 11 commits
  2. 13 Jun, 2019 6 commits
  3. 12 Jun, 2019 19 commits
  4. 11 Jun, 2019 4 commits
    • David S. Miller's avatar
      Merge branch 'tls-add-support-for-kernel-driven-resync-and-nfp-RX-offload' · 758a0a4d
      David S. Miller authored
      Jakub Kicinski says:
      
      ====================
      tls: add support for kernel-driven resync and nfp RX offload
      
      This series adds TLS RX offload for NFP and completes the offload
      by providing resync strategies.  When TLS data stream looses segments
      or experiences reorder NIC can no longer perform in line offload.
      Resyncs provide information about placement of records in the
      stream so that offload can resume.
      
      Existing TLS resync mechanisms are not a great fit for the NFP.
      In particular the TX resync is hard to implement for packet-centric
      NICs.  This patchset adds an ability to perform TX resync in a way
      similar to the way initial sync is done - by calling down to the
      driver when new record is created after driver indicated sync had
      been lost.
      
      Similarly on the RX side, we try to wait for a gap in the stream
      and send record information for the next record.  This works very
      well for RPC workloads which are the primary focus at this time.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      758a0a4d
    • Jakub Kicinski's avatar
      nfp: tls: make use of kernel-driven TX resync · 9ed431c1
      Jakub Kicinski authored
      When TCP stream gets out of sync (driver stops receiving skbs
      with expected TCP sequence numbers) request a TX resync from
      the kernel.
      
      We try to distinguish retransmissions from missed transmissions
      by comparing the sequence number to expected - if it's further
      than the expected one - we probably missed packets.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ed431c1
    • Jakub Kicinski's avatar
      net/tls: add kernel-driven resync mechanism for TX · 50180074
      Jakub Kicinski authored
      TLS offload drivers keep track of TCP seq numbers to make sure
      the packets are fed into the HW in order.
      
      When packets get dropped on the way through the stack, the driver
      will get out of sync and have to use fallback encryption, but unless
      TCP seq number is resynced it will never match the packets correctly
      (or even worse - use incorrect record sequence number after TCP seq
      wraps).
      
      Existing drivers (mlx5) feed the entire record on every out-of-order
      event, allowing FW/HW to always be in sync.
      
      This patch adds an alternative, more akin to the RX resync.  When
      driver sees a frame which is past its expected sequence number the
      stream must have gotten out of order (if the sequence number is
      smaller than expected its likely a retransmission which doesn't
      require resync).  Driver will ask the stack to perform TX sync
      before it submits the next full record, and fall back to software
      crypto until stack has performed the sync.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      50180074
    • Jakub Kicinski's avatar
      net/tls: generalize the resync callback · eeb2efaf
      Jakub Kicinski authored
      Currently only RX direction is ever resynced, however, TX may
      also get out of sequence if packets get dropped on the way to
      the driver.  Rename the resync callback and add a direction
      parameter.
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Reviewed-by: default avatarDirk van der Merwe <dirk.vandermerwe@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eeb2efaf