1. 19 Apr, 2019 1 commit
  2. 18 Apr, 2019 36 commits
  3. 17 Apr, 2019 3 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 6b0a7f84
      David S. Miller authored
      Conflict resolution of af_smc.c from Stephen Rothwell.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b0a7f84
    • David S. Miller's avatar
      Merge branch 's390-next' · cea0aa9c
      David S. Miller authored
      Julian Wiedmann says:
      
      ====================
      s390/qeth: updates 2019-04-17
      
      please apply some additional qeth patches to net-next. This patchset
      converts the driver to use the kernel's multiqueue model.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cea0aa9c
    • Julian Wiedmann's avatar
      s390/qeth: stop/wake TX queues based on their fill level · 54a50941
      Julian Wiedmann authored
      Current xmit code only stops the txq after attempting to fill an
      IO buffer that hasn't been TX-completed yet. In many-connection
      scenarios, this can result in frequent rejected TX attempts, requeuing
      of skbs with NETDEV_TX_BUSY and extra overhead.
      
      Now that we have a proper 1-to-1 relation between stack-side txqs and
      our HW Queues, overhaul the stop/wake logic so that the xmit code
      stops the txq as needed.
      Given that we might map multiple skbs into a single buffer, it's crucial
      to ensure that the queue always provides an _entirely_ empty IO buffer.
      Otherwise large skbs (eg TSO) might not fit into the last available
      buffer. So whenever qeth_do_send_packet() first utilizes an _empty_
      buffer, it updates & checks the used_buffers count.
      
      This now ensures that an skb passed to qeth_xmit() can always be mapped
      into an IO buffer, so remove all of the -EBUSY roll-back handling in the
      TX path. We preserve the minimal safety-checks ("Is this IO buffer
      really available?"), just in case some nasty future bug ever attempts to
      corrupt an in-use buffer.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54a50941