1. 28 4月, 2018 2 次提交
  2. 23 4月, 2018 1 次提交
    • J
      s390/qeth: avoid control IO completion stalls · 901e3f49
      Julian Wiedmann 提交于
      For control IO, qeth currently tracks the index of the buffer that it
      expects to complete the next IO on each qeth_channel. If the channel
      presents an IRQ while this buffer has not yet completed, no completion
      processing for _any_ completed buffer takes place.
      So if the 'next buffer' is skipped for any sort of reason* (eg. when it
      is released due to error conditions, before the IO is started), the
      buffer obviously won't switch to PROCESSED until it is eventually
      allocated for a _different_ IO and completes.
      Until this happens, all completion processing on that channel stalls
      and pending requests possibly time out.
      
      As a fix, remove the whole 'next buffer' logic and simply process any
      IO buffer right when it completes. A channel will never have more than
      one IO pending, so there's no risk of processing out-of-sequence.
      
      *Note: currently just one location in the code really handles this problem,
             by advancing the 'next' index manually.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      901e3f49
  3. 10 3月, 2018 2 次提交
  4. 10 2月, 2018 2 次提交
  5. 21 12月, 2017 5 次提交
  6. 16 12月, 2017 2 次提交
  7. 03 12月, 2017 1 次提交
    • J
      s390/qeth: fix GSO throughput regression · 6d69b1f1
      Julian Wiedmann 提交于
      Using GSO with small MTUs currently results in a substantial throughput
      regression - which is caused by how qeth needs to map non-linear skbs
      into its IO buffer elements:
      compared to a linear skb, each GSO-segmented skb effectively consumes
      twice as many buffer elements (ie two instead of one) due to the
      additional header-only part. This causes the Output Queue to be
      congested with low-utilized IO buffers.
      
      Fix this as follows:
      If the MSS is low enough so that a non-SG GSO segmentation produces
      order-0 skbs (currently ~3500 byte), opt out from NETIF_F_SG. This is
      where we anticipate the biggest savings, since an SG-enabled
      GSO segmentation produces skbs that always consume at least two
      buffer elements.
      
      Larger MSS values continue to get a SG-enabled GSO segmentation, since
      1) the relative overhead of the additional header-only buffer element
      becomes less noticeable, and
      2) the linearization overhead increases.
      
      With the throughput regression fixed, re-enable NETIF_F_SG by default to
      reap the significant CPU savings of GSO.
      
      Fixes: 5722963a ("qeth: do not turn on SG per default")
      Reported-by: NNils Hoppmann <niho@de.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d69b1f1
  8. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman 提交于
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  9. 20 10月, 2017 2 次提交
  10. 19 9月, 2017 5 次提交
    • J
      s390/qeth: tidy up parameter naming for qeth_do_send_packet() · e878c5e6
      Jens Remus 提交于
      Cppcheck reports the following for drivers/s390/net/qeth_core.h:
      
          warning - line 1560 - Function 'qeth_do_send_packet' argument order
          different:
          declaration 'card, queue, skb, hdr, hd_len, offset, elements'
          definition  'card, queue, skb, hdr, offset, hd_len, elements_needed'.
      
      Match the naming in the function's declaration against its definition.
      Signed-off-by: NJens Remus <jremus@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e878c5e6
    • J
      s390/qeth: don't take queue lock in send_packet_fast() · 7c2e9ba3
      Julian Wiedmann 提交于
      Locking the output queue prior to TX is needed on OSA devices,
      to synchronize against a packing flush from the TX completion code
      (via qeth_check_outbound_queue()).
      But send_packet_fast() is only used for IQDs, which don't do packing.
      So remove the locking, and apply some easy cleanups.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Reviewed-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c2e9ba3
    • H
      s390/qeth: add VNICC get/set timeout support · 349d13d5
      Hans Wippel 提交于
      HiperSockets allow configuring so called VNIC Characteristics (VNICC)
      that influence how the underlying hardware handles packets. For VNICCs,
      additional commands for getting and setting timeouts are available.
      Currently, the learning VNICC uses these commands.
      
      * Learning VNICC: If learning is enabled on a qeth device, the device
        learns the source MAC addresses of outgoing packets and incoming
        packets to those learned MAC addresses are received.
      
      For learning, the timeout specifies the idle period in seconds, after
      which the underlying hardware removes a learned MAC address again.
      
      This patch adds support for the IPA commands that are required to get
      and set the current timeout values for the learning VNIC characteristic.
      Also, it introduces the sysfs interface that allows users to configure
      the timeout.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      349d13d5
    • H
      s390/qeth: add VNICC enable/disable support · caa1f0b1
      Hans Wippel 提交于
      HiperSocket devices allow enabling and disabling so called VNIC
      Characteristics (VNICC) that influence how the underlying hardware
      handles packets. These VNICCs are:
      
      * Flooding VNICC: Flooding allows specifying if packets to unknown
        destination MAC addresses are received by the qeth device.
      
      * Multicast flooding VNICC: Multicast flooding allows specifying if
        packets to multicast MAC addresses are received by the qeth device.
      
      * Learning VNICC: If learning is enabled on a qeth device, the device
        learns the source MAC addresses of outgoing packets and incoming
        packets to those learned MAC addresses are received.
      
      * Takeover setvmac VNICC: If takeover setvmac is configured on a qeth
        device, the MAC address of this device can be configured on a
        different qeth device with the setvmac IPA command.
      
      * Takeover by learning VNICC: If takeover learning is enabled on a qeth
        device, the MAC address of this device can be learned (learning VNICC)
        on a different qeth device.
      
      * BridgePort invisible VNICC: If BridgePort invisible is enabled on a
        qeth device, (1) packets from this device are not sent to a BridgePort
        enabled qeth device and (2) packets coming from a BridgePort enabled
        qeth device are not received by this device.
      
      * Receive broadcast VNICC: Receive broadcast allows configuring if a
        qeth device receives packets with the broadcast destination MAC
        address.
      
      This patch adds support for the IPA commands that are required to enable
      and disable these VNIC characteristics on qeth devices. As a
      prerequisite, it also adds the query commands IPA command.
      
      The query commands IPA command allows requesting the supported commands
      for each characteristic from the underlying hardware.
      
      Additionally, this patch provides users with a sysfs user interface to
      enable/disable the VNICCs mentioned above.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caa1f0b1
    • H
      s390/qeth: add basic VNICC support · a45b3faf
      Hans Wippel 提交于
      VNIC Characteristics (VNICC) are features of HiperSockets that define
      how packets are handled by the underlying network hardware. For example,
      if the VNICC flooding is configured on a qeth device, ethernet frames to
      unknown destination MAC addresses are received.
      
      Currently, there is support for seven VNICCs: flooding, multicast
      flooding, receive broadcast, learning, takeover learning, takeover
      setvmac, bridge invisible. Also, six IPA commands exist for configuring
      VNICCs on a qeth device: query characteristics, query commands, enable
      characteristic, disable characteristic, set timeout, get timeout.
      
      This patch adds the basic code infrastructure for VNICC support to qeth.
      It allows querying VNICC support from the underlying hardware. To this
      end, it adds:
      
      * basic message formats for IPA commands
      * basic data structures
      * basic error handling
      * query characteristics IPA command support
      
      The query characteristics IPA command allows requesting the currently
      supported and currently enabled VNIC characteristics from the underlying
      hardware.
      
      Support for the other IPA commands and for the configuration of VNICCs
      is added in follow-up patches together with the respective user
      interface functions.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a45b3faf
  11. 19 8月, 2017 3 次提交
  12. 16 8月, 2017 2 次提交
  13. 21 6月, 2017 1 次提交
  14. 07 6月, 2017 1 次提交
  15. 12 5月, 2017 1 次提交
    • J
      s390/qeth: unbreak OSM and OSN support · 2d2ebb3e
      Julian Wiedmann 提交于
      commit b4d72c08 ("qeth: bridgeport support - basic control")
      broke the support for OSM and OSN devices as follows:
      
      As OSM and OSN are L2 only, qeth_core_probe_device() does an early
      setup by loading the l2 discipline and calling qeth_l2_probe_device().
      In this context, adding the l2-specific bridgeport sysfs attributes
      via qeth_l2_create_device_attributes() hits a BUG_ON in fs/sysfs/group.c,
      since the basic sysfs infrastructure for the device hasn't been
      established yet.
      
      Note that OSN actually has its own unique sysfs attributes
      (qeth_osn_devtype), so the additional attributes shouldn't be created
      at all.
      For OSM, add a new qeth_l2_devtype that contains all the common
      and l2-specific sysfs attributes.
      When qeth_core_probe_device() does early setup for OSM or OSN, assign
      the corresponding devtype so that the ccwgroup probe code creates the
      full set of sysfs attributes.
      This allows us to skip qeth_l2_create_device_attributes() in case
      of an early setup.
      
      Any device that can't do early setup will initially have only the
      generic sysfs attributes, and when it's probed later
      qeth_l2_probe_device() adds the l2-specific attributes.
      
      If an early-setup device is removed (by calling ccwgroup_ungroup()),
      device_unregister() will - using the devtype - delete the
      l2-specific attributes before qeth_l2_remove_device() is called.
      So make sure to not remove them twice.
      
      What complicates the issue is that qeth_l2_probe_device() and
      qeth_l2_remove_device() is also called on a device when its
      layer2 attribute changes (ie. its layer mode is switched).
      For early-setup devices this wouldn't work properly - we wouldn't
      remove the l2-specific attributes when switching to L3.
      But switching the layer mode doesn't actually make any sense;
      we already decided that the device can only operate in L2!
      So just refuse to switch the layer mode on such devices. Note that
      OSN doesn't have a layer2 attribute, so we only need to special-case
      OSM.
      
      Based on an initial patch by Ursula Braun.
      
      Fixes: b4d72c08 ("qeth: bridgeport support - basic control")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d2ebb3e
  16. 12 4月, 2017 7 次提交
  17. 07 4月, 2017 2 次提交