1. 31 Jul, 2017 11 commits
    • Jamal Hadi Salim's avatar
      net sched actions: add time filter for action dumping · e62e484d
      Jamal Hadi Salim authored
      This patch adds support for filtering based on time since last used.
      When we are dumping a large number of actions it is useful to
      have the option of filtering based on when the action was last
      used to reduce the amount of data crossing to user space.
      
      With this patch the user space app sets the TCA_ROOT_TIME_DELTA
      attribute with the value in milliseconds with "time of interest
      since now".  The kernel converts this to jiffies and does the
      filtering comparison matching entries that have seen activity
      since then and returns them to user space.
      Old kernels and old tc continue to work in legacy mode since
      they dont specify this attribute.
      
      Some example (we have 400 actions bound to 400 filters); at
      installation time. Using updated when tc setting the time of
      interest to 120 seconds earlier (we see 400 actions):
      prompt$ hackedtc actions ls action gact since 120000| grep index | wc -l
      400
      
      go get some coffee and wait for > 120 seconds and try again:
      
      prompt$ hackedtc actions ls action gact since 120000 | grep index | wc -l
      0
      
      Lets see a filter bound to one of these actions:
      ....
      filter pref 10 u32
      filter pref 10 u32 fh 800: ht divisor 1
      filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10  (rule hit 2 success 1)
        match 7f000002/ffffffff at 12 (success 1 )
          action order 1: gact action pass
           random type none pass val 0
           index 23 ref 2 bind 1 installed 1145 sec used 802 sec
          Action statistics:
          Sent 84 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
          backlog 0b 0p requeues 0
      ....
      
      that coffee took long, no? It was good.
      
      Now lets ping -c 1 127.0.0.2, then run the actions again:
      prompt$ hackedtc actions ls action gact since 120 | grep index | wc -l
      1
      
      More details please:
      prompt$ hackedtc -s actions ls action gact since 120000
      
          action order 0: gact action pass
           random type none pass val 0
           index 23 ref 2 bind 1 installed 1270 sec used 30 sec
          Action statistics:
          Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
          backlog 0b 0p requeues 0
      
      And the filter?
      
      filter pref 10 u32
      filter pref 10 u32 fh 800: ht divisor 1
      filter pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10  (rule hit 4 success 2)
        match 7f000002/ffffffff at 12 (success 2 )
          action order 1: gact action pass
           random type none pass val 0
           index 23 ref 2 bind 1 installed 1324 sec used 84 sec
          Action statistics:
          Sent 168 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
          backlog 0b 0p requeues 0
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e62e484d
    • Jamal Hadi Salim's avatar
      net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch · 90825b23
      Jamal Hadi Salim authored
      When you dump hundreds of thousands of actions, getting only 32 per
      dump batch even when the socket buffer and memory allocations allow
      is inefficient.
      
      With this change, the user will get as many as possibly fitting
      within the given constraints available to the kernel.
      
      The top level action TLV space is extended. An attribute
      TCA_ROOT_FLAGS is used to carry flags; flag TCA_FLAG_LARGE_DUMP_ON
      is set by the user indicating the user is capable of processing
      these large dumps. Older user space which doesnt set this flag
      doesnt get the large (than 32) batches.
      The kernel uses the TCA_ROOT_COUNT attribute to tell the user how many
      actions are put in a single batch. As such user space app knows how long
      to iterate (independent of the type of action being dumped)
      instead of hardcoded maximum of 32 thus maintaining backward compat.
      
      Some results dumping 1.5M actions below:
      first an unpatched tc which doesnt understand these features...
      
      prompt$ time -p tc actions ls action gact | grep index | wc -l
      1500000
      real 1388.43
      user 2.07
      sys 1386.79
      
      Now lets see a patched tc which sets the correct flags when requesting
      a dump:
      
      prompt$ time -p updatedtc actions ls action gact | grep index | wc -l
      1500000
      real 178.13
      user 2.02
      sys 176.96
      
      That is about 8x performance improvement for tc app which sets its
      receive buffer to about 32K.
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90825b23
    • Jamal Hadi Salim's avatar
      net sched actions: Use proper root attribute table for actions · df823b02
      Jamal Hadi Salim authored
      Bug fix for an issue which has been around for about a decade.
      We got away with it because the enumeration was larger than needed.
      
      Fixes: 7ba699c6 ("[NET_SCHED]: Convert actions from rtnetlink to new netlink API")
      Suggested-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df823b02
    • Jamal Hadi Salim's avatar
      net netlink: Add new type NLA_BITFIELD32 · 64c83d83
      Jamal Hadi Salim authored
      Generic bitflags attribute content sent to the kernel by user.
      With this netlink attr type the user can either set or unset a
      flag in the kernel.
      
      The value is a bitmap that defines the bit values being set
      The selector is a bitmask that defines which value bit is to be
      considered.
      
      A check is made to ensure the rules that a kernel subsystem always
      conforms to bitflags the kernel already knows about. i.e
      if the user tries to set a bit flag that is not understood then
      the _it will be rejected_.
      
      In the most basic form, the user specifies the attribute policy as:
      [ATTR_GOO] = { .type = NLA_BITFIELD32, .validation_data = &myvalidflags },
      
      where myvalidflags is the bit mask of the flags the kernel understands.
      
      If the user _does not_ provide myvalidflags then the attribute will
      also be rejected.
      
      Examples:
      value = 0x0, and selector = 0x1
      implies we are selecting bit 1 and we want to set its value to 0.
      
      value = 0x2, and selector = 0x2
      implies we are selecting bit 2 and we want to set its value to 1.
      Suggested-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64c83d83
    • Andrew Lunn's avatar
      net: fec: Allow reception of frames bigger than 1522 bytes · fbbeefdd
      Andrew Lunn authored
      The FEC Receive Control Register has a 14 bit field indicating the
      longest frame that may be received. It is being set to 1522. Frames
      longer than this are discarded, but counted as being in error.
      
      When using DSA, frames from the switch has an additional header,
      either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
      of 1522 bytes received by the switch on a port becomes 1530 bytes when
      passed to the host via the FEC interface.
      
      Change the maximum receive size to 2048 - 64, where 64 is the maximum
      rx_alignment applied on the receive buffer for AVB capable FEC
      cores. Use this value also for the maximum receive buffer size. The
      driver is already allocating a receive SKB of 2048 bytes, so this
      change should not have any significant effects.
      
      Tested on imx51, imx6, vf610.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fbbeefdd
    • Andrew Lunn's avatar
      net: fec: Issue error for missing but expected PHY · 9558df3a
      Andrew Lunn authored
      If the PHY is missing but expected, e.g. because of a typ0 in the dt
      file, it is not possible to open the interface. ip link returns:
      
      RTNETLINK answers: No such device
      
      It is not very obvious what the problem is. Add a netdev_err() in this
      case to make it easier to debug the issue.
      
      [   21.409385] fec 2188000.ethernet eth0: Unable to connect to phy
      RTNETLINK answers: No such device
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9558df3a
    • David S. Miller's avatar
      Merge branch 'dsa-lan9303-Fix-MDIO-issues' · 509394e8
      David S. Miller authored
      Egil Hjelmeland says:
      
      ====================
      net: dsa: lan9303: Fix MDIO issues.
      
      This series fix the MDIO interface for the lan9303 DSA driver.
      Bugs found after testing on actual HW.
      
      This series is extracted from the first patch of my first large
      series. Significant changes from that version are:
       - use mdiobus_write_nested, mdiobus_read_nested.
       - EXPORT lan9303_indirect_phy_ops
      
      Unfortunately I do not have access to i2c based system for
      testing.
      
      Changes from first version:
       - Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      509394e8
    • Egil Hjelmeland's avatar
      net: dsa: lan9303: MDIO access phy registers directly · 2c340898
      Egil Hjelmeland authored
      Indirect access (PMI) to phy register only work in I2C mode. In
      MDIO mode phy registers must be accessed directly. Introduced
      struct lan9303_phy_ops to handle the two modes.
      Signed-off-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c340898
    • Egil Hjelmeland's avatar
      net: dsa: lan9303: Renamed indirect phy access functions · 9e866e5d
      Egil Hjelmeland authored
      Preparing for the following fix of MDIO phy access:
      
      Renamed functions that access PHY 1 and 2 indirectly through PMI
      registers.
      
       lan9303_port_phy_reg_wait_for_completion() to
       lan9303_indirect_phy_wait_for_completion()
      
       lan9303_port_phy_reg_read() to
       lan9303_indirect_phy_read()
      
       lan9303_port_phy_reg_write() to
       lan9303_indirect_phy_write()
      
      Also changed "val" parameter of lan9303_indirect_phy_write() to u16,
      for clarity.
      Signed-off-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e866e5d
    • Egil Hjelmeland's avatar
      net: dsa: lan9303: Multiply by 4 to get MDIO register · ab78acb1
      Egil Hjelmeland authored
      lan9303_mdio_write()/_read() must multiply register number by 4 to get
      offset.
      
      Added some commments to the register definitions.
      Signed-off-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab78acb1
    • Egil Hjelmeland's avatar
      net: dsa: lan9303: Fix lan9303_detect_phy_setup() for MDIO · d329ac88
      Egil Hjelmeland authored
      Handle that MDIO read with no response return 0xffff.
      Signed-off-by: default avatarEgil Hjelmeland <privat@egil-hjelmeland.no>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d329ac88
  2. 30 Jul, 2017 4 commits
    • David S. Miller's avatar
      Merge branch 'ethtool-fec' · 736b9b9c
      David S. Miller authored
      Roopa Prabhu says:
      
      ====================
      ethtool: support for forward error correction mode setting on a link
      
      Forward Error Correction (FEC) modes i.e Base-R
      and Reed-Solomon modes are introduced in 25G/40G/100G standards
      for providing good BER at high speeds. Various networking devices
      which support 25G/40G/100G provides ability to manage supported FEC
      modes and the lack of FEC encoding control and reporting today is a
      source for interoperability issues for many vendors.
      FEC capability as well as specific FEC mode i.e. Base-R
      or RS modes can be requested or advertised through bits D44:47 of base link
      codeword.
      
      This patch set intends to provide option under ethtool to manage and
      report FEC encoding settings for networking devices as per IEEE 802.3
      bj, bm and by specs.
      
      v2 :
              - minor patch format fixes and typos pointed out by Andrew
              - there was a pending discussion on the use of 'auto' vs
                'automatic' for fec settings. I have left it as 'auto'
                because in most cases today auto is used in place of
                automatic to represent automatically generated values.
                We use it in other networking config too. I would prefer
                leaving it as auto.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      736b9b9c
    • Casey Leedom's avatar
    • Casey Leedom's avatar
    • Vidya Sagar Ravipati's avatar
      net: ethtool: add support for forward error correction modes · 1a5f3da2
      Vidya Sagar Ravipati authored
      Forward Error Correction (FEC) modes i.e Base-R
      and Reed-Solomon modes are introduced in 25G/40G/100G standards
      for providing good BER at high speeds. Various networking devices
      which support 25G/40G/100G provides ability to manage supported FEC
      modes and the lack of FEC encoding control and reporting today is a
      source for interoperability issues for many vendors.
      FEC capability as well as specific FEC mode i.e. Base-R
      or RS modes can be requested or advertised through bits D44:47 of
      base link codeword.
      
      This patch set intends to provide option under ethtool to manage
      and report FEC encoding settings for networking devices as per
      IEEE 802.3 bj, bm and by specs.
      
      set-fec/show-fec option(s) are designed to provide control and
      report the FEC encoding on the link.
      
      SET FEC option:
      root@tor: ethtool --set-fec  swp1 encoding [off | RS | BaseR | auto]
      
      Encoding: Types of encoding
      Off    :  Turning off any encoding
      RS     :  enforcing RS-FEC encoding on supported speeds
      BaseR  :  enforcing Base R encoding on supported speeds
      Auto   :  IEEE defaults for the speed/medium combination
      
      Here are a few examples of what we would expect if encoding=auto:
      - if autoneg is on, we are  expecting FEC to be negotiated as on or off
        as long as protocol supports it
      - if the hardware is capable of detecting the FEC encoding on it's
            receiver it will reconfigure its encoder to match
      - in absence of the above, the configuration would be set to IEEE
        defaults.
      
      >From our  understanding , this is essentially what most hardware/driver
      combinations are doing today in the absence of a way for users to
      control the behavior.
      
      SHOW FEC option:
      root@tor: ethtool --show-fec  swp1
      FEC parameters for swp1:
      Active FEC encodings: RS
      Configured FEC encodings:  RS | BaseR
      
      ETHTOOL DEVNAME output modification:
      
      ethtool devname output:
      root@tor:~# ethtool swp1
      Settings for swp1:
      root@hpe-7712-03:~# ethtool swp18
      Settings for swp18:
          Supported ports: [ FIBRE ]
          Supported link modes:   40000baseCR4/Full
                                  40000baseSR4/Full
                                  40000baseLR4/Full
                                  100000baseSR4/Full
                                  100000baseCR4/Full
                                  100000baseLR4_ER4/Full
          Supported pause frame use: No
          Supports auto-negotiation: Yes
          Supported FEC modes: [RS | BaseR | None | Not reported]
          Advertised link modes:  Not reported
          Advertised pause frame use: No
          Advertised auto-negotiation: No
          Advertised FEC modes: [RS | BaseR | None | Not reported]
      <<<< One or more FEC modes
          Speed: 100000Mb/s
          Duplex: Full
          Port: FIBRE
          PHYAD: 106
          Transceiver: internal
          Auto-negotiation: off
          Link detected: yes
      
      This patch includes following changes
      a) New ETHTOOL_SFECPARAM/SFECPARAM API, handled by
        the new get_fecparam/set_fecparam callbacks, provides support
        for configuration of forward error correction modes.
      b) Link mode bits for FEC modes i.e. None (No FEC mode), RS, BaseR/FC
        are defined so that users can configure these fec modes for supported
        and advertising fields as part of link autonegotiation.
      Signed-off-by: default avatarVidya Sagar Ravipati <vidya.chowdary@gmail.com>
      Signed-off-by: default avatarDustin Byford <dustin@cumulusnetworks.com>
      Signed-off-by: default avatarRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a5f3da2
  3. 29 Jul, 2017 25 commits