1. 03 Jun, 2016 1 commit
    • Marcelo Ricardo Leitner's avatar
      sctp: Add GSO support · 90017acc
      Marcelo Ricardo Leitner authored
      SCTP has this pecualiarity that its packets cannot be just segmented to
      (P)MTU. Its chunks must be contained in IP segments, padding respected.
      So we can't just generate a big skb, set gso_size to the fragmentation
      point and deliver it to IP layer.
      
      This patch takes a different approach. SCTP will now build a skb as it
      would be if it was received using GRO. That is, there will be a cover
      skb with protocol headers and children ones containing the actual
      segments, already segmented to a way that respects SCTP RFCs.
      
      With that, we can tell skb_segment() to just split based on frag_list,
      trusting its sizes are already in accordance.
      
      This way SCTP can benefit from GSO and instead of passing several
      packets through the stack, it can pass a single large packet.
      
      v2:
      - Added support for receiving GSO frames, as requested by Dave Miller.
      - Clear skb->cb if packet is GSO (otherwise it's not used by SCTP)
      - Added heuristics similar to what we have in TCP for not generating
        single GSO packets that fills cwnd.
      v3:
      - consider sctphdr size in skb_gso_transport_seglen()
      - rebased due to 5c7cdf33
      
       ("gso: Remove arbitrary checks for
        unsupported GSO")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Tested-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90017acc
  2. 20 May, 2016 1 commit
  3. 18 Apr, 2016 1 commit
  4. 14 Apr, 2016 3 commits
    • Alexander Duyck's avatar
      GSO: Support partial segmentation offload · 802ab55a
      Alexander Duyck authored
      
      
      This patch adds support for something I am referring to as GSO partial.
      The basic idea is that we can support a broader range of devices for
      segmentation if we use fixed outer headers and have the hardware only
      really deal with segmenting the inner header.  The idea behind the naming
      is due to the fact that everything before csum_start will be fixed headers,
      and everything after will be the region that is handled by hardware.
      
      With the current implementation it allows us to add support for the
      following GSO types with an inner TSO_MANGLEID or TSO6 offload:
      NETIF_F_GSO_GRE
      NETIF_F_GSO_GRE_CSUM
      NETIF_F_GSO_IPIP
      NETIF_F_GSO_SIT
      NETIF_F_UDP_TUNNEL
      NETIF_F_UDP_TUNNEL_CSUM
      
      In the case of hardware that already supports tunneling we may be able to
      extend this further to support TSO_TCPV4 without TSO_MANGLEID if the
      hardware can support updating inner IPv4 headers.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      802ab55a
    • Alexander Duyck's avatar
      GSO: Add GSO type for fixed IPv4 ID · cbc53e08
      Alexander Duyck authored
      
      
      This patch adds support for TSO using IPv4 headers with a fixed IP ID
      field.  This is meant to allow us to do a lossless GRO in the case of TCP
      flows that use a fixed IP ID such as those that convert IPv6 header to IPv4
      headers.
      
      In addition I am adding a feature that for now I am referring to TSO with
      IP ID mangling.  Basically when this flag is enabled the device has the
      option to either output the flow with incrementing IP IDs or with a fixed
      IP ID regardless of what the original IP ID ordering was.  This is useful
      in cases where the DF bit is set and we do not care if the original IP ID
      value is maintained.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbc53e08
    • Alexander Duyck's avatar
      ethtool: Add support for toggling any of the GSO offloads · 518f213d
      Alexander Duyck authored
      
      
      The strings were missing for several of the GSO offloads that are
      available.  This patch provides the missing strings so that we can toggle
      or query any of them via the ethtool command.
      Signed-off-by: default avatarAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      518f213d
  5. 16 Mar, 2016 1 commit
  6. 26 Feb, 2016 2 commits
    • David Decotigny's avatar
      net: ethtool: remove unused __ethtool_get_settings · 3237fc63
      David Decotigny authored
      
      
      replaced by __ethtool_get_link_ksettings.
      Signed-off-by: default avatarDavid Decotigny <decot@googlers.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3237fc63
    • David Decotigny's avatar
      net: ethtool: add new ETHTOOL_xLINKSETTINGS API · 3f1ac7a7
      David Decotigny authored
      
      
      This patch defines a new ETHTOOL_GLINKSETTINGS/SLINKSETTINGS API,
      handled by the new get_link_ksettings/set_link_ksettings callbacks.
      This API provides support for most legacy ethtool_cmd fields, adds
      support for larger link mode masks (up to 4064 bits, variable length),
      and removes ethtool_cmd deprecated
      fields (transceiver/maxrxpkt/maxtxpkt).
      
      This API is deprecating the legacy ETHTOOL_GSET/SSET API and provides
      the following backward compatibility properties:
       - legacy ethtool with legacy drivers: no change, still using the
         get_settings/set_settings callbacks.
       - legacy ethtool with new get/set_link_ksettings drivers: the new
         driver callbacks are used, data internally converted to legacy
         ethtool_cmd. ETHTOOL_GSET will return only the 1st 32b of each link
         mode mask. ETHTOOL_SSET will fail if user tries to set the
         ethtool_cmd deprecated fields to
         non-0 (transceiver/maxrxpkt/maxtxpkt). A kernel warning is logged if
         driver sets higher bits.
       - future ethtool with legacy drivers: no change, still using the
         get_settings/set_settings callbacks, internally converted to new data
         structure. Deprecated fields (transceiver/maxrxpkt/maxtxpkt) will be
         ignored and seen as 0 from user space. Note that that "future"
         ethtool tool will not allow changes to these deprecated fields.
       - future ethtool with new drivers: direct call to the new callbacks.
      
      By "future" ethtool, what is meant is:
       - query: first try ETHTOOL_GLINKSETTINGS, and revert to ETHTOOL_GSET if
         fails
       - set: query first and remember which of ETHTOOL_GLINKSETTINGS or
         ETHTOOL_GSET was successful
         + if ETHTOOL_GLINKSETTINGS was successful, then change config with
           ETHTOOL_SLINKSETTINGS. A failure there is final (do not try
           ETHTOOL_SSET).
         + otherwise ETHTOOL_GSET was successful, change config with
           ETHTOOL_SSET. A failure there is final (do not try
           ETHTOOL_SLINKSETTINGS).
      
      The interaction user/kernel via the new API requires a small
      ETHTOOL_GLINKSETTINGS handshake first to agree on the length of the link
      mode bitmaps. If kernel doesn't agree with user, it returns the bitmap
      length it is expecting from user as a negative length (and cmd field is
      0). When kernel and user agree, kernel returns valid info in all
      fields (ie. link mode length > 0 and cmd is ETHTOOL_GLINKSETTINGS).
      
      Data structure crossing user/kernel boundary is 32/64-bit
      agnostic. Converted internally to a legal kernel bitmap.
      
      The internal __ethtool_get_settings kernel helper will gradually be
      replaced by __ethtool_get_link_ksettings by the time the first
      "link_settings" drivers start to appear. So this patch doesn't change
      it, it will be removed before it needs to be changed.
      Signed-off-by: default avatarDavid Decotigny <decot@googlers.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f1ac7a7
  7. 20 Feb, 2016 3 commits
  8. 17 Feb, 2016 1 commit
  9. 16 Feb, 2016 2 commits
    • Keller, Jacob E's avatar
      ethtool: ensure channel counts are within bounds during SCHANNELS · 8bf36862
      Keller, Jacob E authored
      
      
      Add a sanity check to ensure that all requested channel sizes are within
      bounds, which should reduce errors in driver implementation.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bf36862
    • Keller, Jacob E's avatar
      ethtool: correctly ensure {GS}CHANNELS doesn't conflict with GS{RXFH} · d4ab4286
      Keller, Jacob E authored
      
      
      Ethernet drivers implementing both {GS}RXFH and {GS}CHANNELS ethtool ops
      incorrectly allow SCHANNELS when it would conflict with the settings
      from SRXFH. This occurs because it is not possible for drivers to
      understand whether their Rx flow indirection table has been configured
      or is in the default state. In addition, drivers currently behave in
      various ways when increasing the number of Rx channels.
      
      Some drivers will always destroy the Rx flow indirection table when this
      occurs, whether it has been set by the user or not. Other drivers will
      attempt to preserve the table even if the user has never modified it
      from the default driver settings. Neither of these situation is
      desirable because it leads to unexpected behavior or loss of user
      configuration.
      
      The correct behavior is to simply return -EINVAL when SCHANNELS would
      conflict with the current Rx flow table settings. However, it should
      only do so if the current settings were modified by the user. If we
      required that the new settings never conflict with the current (default)
      Rx flow settings, we would force users to first reduce their Rx flow
      settings and then reduce the number of Rx channels.
      
      This patch proposes a solution implemented in net/core/ethtool.c which
      ensures that all drivers behave correctly. It checks whether the RXFH
      table has been configured to non-default settings, and stores this
      information in a private netdev flag. When the number of channels is
      requested to change, it first ensures that the current Rx flow table is
      not going to assign flows to now disabled channels.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4ab4286
  10. 06 Feb, 2016 1 commit
  11. 31 Dec, 2015 1 commit
  12. 15 Dec, 2015 2 commits
    • Tom Herbert's avatar
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert authored
      
      
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a188222b
    • Tom Herbert's avatar
      sctp: Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC · 53692b1d
      Tom Herbert authored
      
      
      The SCTP checksum is really a CRC and is very different from the
      standards 1's complement checksum that serves as the checksum
      for IP protocols. This offload interface is also very different.
      Rename NETIF_F_SCTP_CSUM to NETIF_F_SCTP_CRC to highlight these
      differences. The term CSUM should be reserved in the stack to refer
      to the standard 1's complement IP checksum.
      Signed-off-by: default avatarTom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53692b1d
  13. 15 Oct, 2015 1 commit
  14. 11 Jun, 2015 1 commit
  15. 01 Jun, 2015 1 commit
  16. 22 May, 2015 1 commit
    • Arun Parameswaran's avatar
      net: core: 'ethtool' issue with querying phy settings · f96dee13
      Arun Parameswaran authored
      
      
      When trying to configure the settings for PHY1, using commands
      like 'ethtool -s eth0 phyad 1 speed 100', the 'ethtool' seems to
      modify other settings apart from the speed of the PHY1, in the
      above case.
      
      The ethtool seems to query the settings for PHY0, and use this
      as the base to apply the new settings to the PHY1. This is
      causing the other settings of the PHY 1 to be wrongly
      configured.
      
      The issue is caused by the '_ethtool_get_settings()' API, which
      gets called because of the 'ETHTOOL_GSET' command, is clearing
      the 'cmd' pointer (of type 'struct ethtool_cmd') by calling
      memset. This clears all the parameters (if any) passed for the
      'ETHTOOL_GSET' cmd. So the driver's callback is always invoked
      with 'cmd->phy_address' as '0'.
      
      The '_ethtool_get_settings()' is called from other files in the
      'net/core'. So the fix is applied to the 'ethtool_get_settings()'
      which is only called in the context of the 'ethtool'.
      Signed-off-by: default avatarArun Parameswaran <aparames@broadcom.com>
      Reviewed-by: default avatarRay Jui <rjui@broadcom.com>
      Reviewed-by: default avatarScott Branden <sbranden@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f96dee13
  17. 12 May, 2015 1 commit
  18. 22 Feb, 2015 1 commit
  19. 20 Feb, 2015 1 commit
  20. 06 Jan, 2015 1 commit
  21. 09 Dec, 2014 1 commit
    • Eyal Perry's avatar
      ethtool: Support for configurable RSS hash function · 892311f6
      Eyal Perry authored
      
      
      This patch extends the set/get_rxfh ethtool-options for getting or
      setting the RSS hash function.
      
      It modifies drivers implementation of set/get_rxfh accordingly.
      
      This change also delegates the responsibility of checking whether a
      modification to a certain RX flow hash parameter is supported to the
      driver implementation of set_rxfh.
      
      User-kernel API is done through the new hfunc bitmask field in the
      ethtool_rxfh struct. A bit set in the hfunc field is corresponding to an
      index in the new string-set ETH_SS_RSS_HASH_FUNCS.
      
      Got approval from most of the relevant driver maintainers that their
      driver is using Toeplitz, and for the few that didn't answered, also
      assumed it is Toeplitz.
      
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Ariel Elior <ariel.elior@qlogic.com>
      Cc: Prashant Sreedharan <prashant@broadcom.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: Hariprasad S <hariprasad@chelsio.com>
      Cc: Sathya Perla <sathya.perla@emulex.com>
      Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
      Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Don Skidmore <donald.c.skidmore@intel.com>
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Cc: Matthew Vick <matthew.vick@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Mitch Williams <mitch.a.williams@intel.com>
      Cc: Amir Vadai <amirv@mellanox.com>
      Cc: Solarflare linux maintainers <linux-net-drivers@solarflare.com>
      Cc: Shradha Shah <sshah@solarflare.com>
      Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
      Cc: "VMware, Inc." <pv-drivers@vmware.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarEyal Perry <eyalpe@mellanox.com>
      Signed-off-by: default avatarAmir Vadai <amirv@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      892311f6
  22. 16 Nov, 2014 1 commit
    • Eric Dumazet's avatar
      net: provide a per host RSS key generic infrastructure · 960fb622
      Eric Dumazet authored
      
      
      RSS (Receive Side Scaling) typically uses Toeplitz hash and a 40 or 52 bytes
      RSS key.
      
      Some drivers use a constant (and well known key), some drivers use a random
      key per port, making bonding setups hard to tune. Well known keys increase
      attack surface, considering that number of queues is usually a power of two.
      
      This patch provides infrastructure to help drivers doing the right thing.
      
      netdev_rss_key_fill() should be used by drivers to initialize their RSS key,
      even if they provide ethtool -X support to let user redefine the key later.
      
      A new /proc/sys/net/core/netdev_rss_key file can be used to get the host
      RSS key even for drivers not providing ethtool -x support, in case some
      applications want to precisely setup flows to match some RX queues.
      
      Tested:
      
      myhost:~# cat /proc/sys/net/core/netdev_rss_key
      11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41:36:40:74:b6:15:ca:27:44:aa:b3:4d:72
      
      myhost:~# ethtool -x eth0
      RX flow hash indirection table for eth0 with 8 RX ring(s):
          0:      0     1     2     3     4     5     6     7
      RSS hash key:
      11:63:99:bb:79:fb:a5:a7:07:45:b2:20:bf:02:42:2d:08:1a:dd:19:2b:6b:23:ac:56:28:9d:70:c3:ac:e8:16:4b:b7:c1:10:53:a4:78:41
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      960fb622
  23. 06 Nov, 2014 1 commit
  24. 31 Oct, 2014 1 commit
  25. 06 Oct, 2014 1 commit
  26. 05 Sep, 2014 1 commit
  27. 03 Jun, 2014 2 commits
  28. 19 May, 2014 3 commits
  29. 28 Apr, 2014 1 commit
  30. 23 Apr, 2014 1 commit