1. 16 Oct, 2018 9 commits
    • Toshiaki Makita's avatar
      veth: Add ethtool statistics support for XDP · d397b968
      Toshiaki Makita authored
      Expose per-queue stats for ethtool -S.
      As there are only rx queues, and rx queues are used only when XDP is
      used, per-queue counters are only rx XDP ones.
      
      Example:
      
      $ ethtool -S veth0
      NIC statistics:
           peer_ifindex: 11
           rx_queue_0_xdp_packets: 28601434
           rx_queue_0_xdp_bytes: 1716086040
           rx_queue_0_xdp_drops: 28601434
           rx_queue_1_xdp_packets: 17873050
           rx_queue_1_xdp_bytes: 1072383000
           rx_queue_1_xdp_drops: 17873050
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d397b968
    • Toshiaki Makita's avatar
      veth: Account for XDP packet statistics on rx side · 4195e54a
      Toshiaki Makita authored
      On XDP path veth has napi handler so we can collect statistics on
      per-queue basis for XDP.
      
      By this change now we can collect XDP_DROP drop count as well as packets
      and bytes coming through ndo_xdp_xmit. Packet counters shown by
      "ip -s link", sysfs stats or /proc/net/dev is now correct for XDP.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4195e54a
    • Toshiaki Makita's avatar
      veth: Account for packet drops in ndo_xdp_xmit · 2131479d
      Toshiaki Makita authored
      Use existing atomic drop counter. Since drop path is really an
      exceptional case here, I'm thinking atomic ops would not hurt the
      performance.
      XDP packets and bytes are not counted in ndo_xdp_xmit, but will be
      accounted on rx side by the following commit.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2131479d
    • Hoang Le's avatar
      tipc: support binding to specific ip address when activating UDP bearer · acad76a5
      Hoang Le authored
      INADDR_ANY is hard-coded when activating UDP bearer. So, we could not
      bind to a specific IP address even with replicast mode using - given
      remote ip address instead of using multicast ip address.
      
      In this commit, we fixed it by checking and switch to use appropriate
      local ip address.
      
      before:
      $netstat -plu
      Active Internet connections (only servers)
      Proto Recv-Q Send-Q Local Address           Foreign Address
      udp        0      0 **0.0.0.0:6118**            0.0.0.0:*
      
      after:
      $netstat -plu
      Active Internet connections (only servers)
      Proto Recv-Q Send-Q Local Address           Foreign Address
      udp        0      0 **10.0.0.2:6118**           0.0.0.0:*
      Acked-by: default avatarYing Xue <ying.xue@windriver.com>
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarHoang Le <hoang.h.le@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acad76a5
    • David S. Miller's avatar
      Merge tag 'mlx5e-updates-2018-10-10' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 1986647c
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5e-updates-2018-10-10
      
      IPoIB netlink support and mlx5e pre-allocated netdevice initialization
      
      IP link was broken due to the changes in IPoIB for the rdma_netdev
      support after commit cd565b4b
      ("IB/IPoIB: Support acceleration options callbacks").
      
      This patchset fixes IPoIB pkey creation and removal using rtnetlink by
      adding support in both IPoIB ULP layer and mlx5 layer:
      
      From Jason and Denis:
      1) Introduces changes in the RDMA netdev code in order to
         allow allocation of the netdev to be done by the rtnl netdev code.
      2) Reworks IPoIB initialization to use the two step rdma_netdev
         creation.
      
      From Feras and Saeed, mlx5e netdev layer refactoring to allow accepting
      pre-allocated netdevs:
      3) Adds support to initialize/cleanup netdevs that are not created
         by mlx5 driver.
      4) Change mlx5e netdevice layer to accept the pre-allocated netdevice
         queue number.
      5) Initialize mlx5e generic structures in one place to be used for all
         netdevs types NIC/representors/IPoIB (both mlx5 allocated and
         pre-allocted).
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1986647c
    • David S. Miller's avatar
      Merge branch 'defza-fddi' · 3325cf9e
      David S. Miller authored
      Maciej W. Rozycki says:
      
      ====================
      FDDI: DEC FDDIcontroller 700 TURBOchannel adapter support
      
       This is an update to <http://patchwork.ozlabs.org/patch/342737/>.  I
      believe I have addressed all the requests made in the previous review
      round.
      
       There is still one `checkpatch.pl' warning remaining:
      
      WARNING: quoted string split across lines
      +       pr_info("%s: ROM rev. %.4s, firmware rev. %.4s, RMC rev. %.4s, "
      +               "SMT ver. %u\n", fp->name, rom_rev, fw_rev, rmc_rev, smt_ver);
      
      total: 0 errors, 1 warnings, 2458 lines checked
      
      however I think the value of staying within 80 columns is higher than the
      value of having the string on a single line.  This is because with all the
      formatting specifiers there it is not directly greppable based on the
      final output produced to the kernel log on one hand, e.g.:
      
      tc2: ROM rev. 1.0, firmware rev. 1.2, RMC rev. A, SMT ver. 1
      
      while it can be easily tracked down by grepping for an obvious substring
      such as "RMC rev" on the other.
      
       The issue with MMIO barriers I discussed in the course of the original
      review turned out mostly irrelevant to this driver, because as I have
      learnt in a recent Alpha/Linux discussion starting here:
      <https://marc.info/?i=alpine.LRH.2.02.1808161556450.13597%20()%20file01%20!%20intranet%20!%20prod%20!%20int%20!%20rdu2%20!%20redhat%20!%20com>
      our MMIO API mandates the `readX' and `writeX' accessors to be strongly
      ordered with respect to each other, even if that is not implicitly
      enforced by hardware.
      
       Consequently I have removed all the explicit ordering barriers and
      instead submitted a fix for MIPS MMIO implementation, which currently does
      not guarantee strong ordering (the MIPS architecture does not define bus
      ordering rules except in terms of SYNC barriers), as recorded here:
      <https://patchwork.linux-mips.org/project/linux-mips/list/?series=1538>.
      
       Enforcing strong MMIO ordering can be costly however and is often
      unnecessary, e.g. when using PIO to access network frame data in onboard
      packet memory.  I have therefore retained the information that would be
      lost by the removal of barriers, by defining accessor wrappers suffixed by
      `_o' and `_u', for accesses that have to be ordered and can be unordered
      respectively.
      
       If we ever have an API defined for weakly-ordered MMIO accesses, then
      these wrappers can be redefined accordingly.  Right now they all expand to
      the respective `_relaxed' accessors, because, again, enforcing the
      ordering WRT DMA transfers can be costly and we don't need it here except
      in one place, where I chose to use explicit `dma_rmb' instead.
      
       Similarly I have replaced the completion barriers with a read back from
      the respective MMIO location (all adapter MMIO registers can be read with
      no side effects incurred), which will serve its purpose on the basis of
      MMIO being strongly ordered (although a read from TURBOchannel is going to
      be slower than `iob', making the delay incurred unnecessarily longer).
      
       And last but not least, I have split off the SMT Tx network tap support
      to a separate change, 2/2 in this series, so that it does not block the
      driver proper and can be discussed separately.
      
       I think it has value in that it makes the view of the outgoing network
      traffic complete, as if one actually physically tapped into the outgoing
      line of the ring, between the station being examined and its downstream
      neighbour.  Without this part only traffic passed from applications
      through the whole protocol stack can be captured and this is only a part
      of the view.
      
       With the `dev_queue_xmit_nit' interface now exported it's only
      `ptype_all' that remains private, and to define a properly abstracted API
      I propose to provide am exported `dev_nit_active' predicate that tells
      whether any taps are active.  This predicate is then used accordingly.
      
       NB if there is a long-term maintenance concern about the `dev_nit_active'
      predicate, then well, corresponding inline code currently present in
      `xmit_one' has to be maintained anyway, and if the resulting changes
      require `defza' to be updated accordingly, then I am going to handle it;
      after some 20 years with Linux it's not that I am going to disappear
      anywhere anytime.  And once I am dead, which is inevitably going to happen
      sooner or later, then the driver can simply be ripped from the kernel.
      Though I suspect that at that point no DECstation Linux users may survive
      anymore, even though hardware, being as sturdy as it is, likely will.
      
       I have a patch for `tcpdump' to actually decode SMT frames, which I plan
      to upstream sometime.  Here's a sample of SMT traffic captured through the
      `defza' driver in a small network of 4 stations and no concentrators,
      printed in the most verbose mode:
      
      01:16:59.138381 4f 00:60:b0:58:41:e7 00:60:b0:58:41:e7 73: SMT NIF ann vid:1 tid:00000270 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:00.332750 4f 08:00:2b:a3:a3:29 08:00:2b:a3:a3:29 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:00.354479 4f 00:60:b0:58:40:75 00:60:b0:58:40:75 73: SMT NIF ann vid:1 tid:0000029c sid:00-00-00-60-b0-58-40-75 len:40: UNA: 00 00 10 00 d4 74 b6 ae StationDescr: 00 01 02 00 StationState: 00 00 31 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:00.442175 4f 00:60:b0:58:41:e7 Broadcast 73: SMT NIF req vid:1 tid:00000271 sid:00-00-00-60-b0-58-41-e7 len:40: UNA: 00 00 00 06 0d 1a 02 ae StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:00.448657 41 08:00:2b:a3:a3:29 00:60:b0:58:41:e7 73: SMT NIF rsp vid:1 tid:00000271 sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:01.015152 4f 08:00:2b:a3:a3:29 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-a3-a3-29 len:40: UNA: 00 00 00 06 0d 1a 82 e7 StationDescr: 00 01 02 00 StationState: 00 00 30 00 MACFrameStatusFunctions.3: 00 00 00 01
      01:17:01.111644 41 08:00:2b:2e:6d:75 08:00:2b:a3:a3:29 73: SMT NIF rsp vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
      01:17:04.814603 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
      01:17:04.814939 4f 08:00:2b:2e:6d:75 Broadcast 73: SMT NIF req vid:1 tid:0000013c sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
      01:17:04.820960 4f 08:00:2b:2e:6d:75 08:00:2b:2e:6d:75 73: SMT NIF ann vid:1 tid:0000013b sid:00-00-08-00-2b-2e-6d-75 len:40: UNA: 00 00 10 00 d4 c5 c5 94 StationDescr: 00 01 01 00 StationState: 00 00 11 00 MACFrameStatusFunctions.2: 00 00 00 01
      
       Questions, comments?  Otherwise, please apply.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3325cf9e
    • Maciej W. Rozycki's avatar
      FDDI: defza: Support capturing outgoing SMT traffic · 9f9a742d
      Maciej W. Rozycki authored
      DEC FDDIcontroller 700 (DEFZA) uses a Tx/Rx queue pair to communicate
      SMT frames with adapter's firmware.  Any SMT frame received from the RMC
      via the Rx queue is queued back by the driver to the SMT Rx queue for
      the firmware to process.  Similarly the firmware uses the SMT Tx queue
      to supply the driver with SMT frames which are queued back to the Tx
      queue for the RMC to send to the ring.
      
      When a network tap is attached to an FDDI interface handled by `defza'
      any incoming SMT frames captured are queued to our usual processing of
      network data received, which in turn delivers them to any listening
      taps.
      
      However the outgoing SMT frames produced by the firmware bypass our
      network protocol stack and are therefore not delivered to taps.  This in
      turn means that taps are missing a part of network traffic sent by the
      adapter, which may make it more difficult to track down network problems
      or do general traffic analysis.
      
      Call `dev_queue_xmit_nit' then in the SMT Tx path, having checked that
      a network tap is attached, with a newly-created `dev_nit_active' helper
      wrapping the usual condition used in the transmit path.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f9a742d
    • Maciej W. Rozycki's avatar
      FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter · 61414f5e
      Maciej W. Rozycki authored
      Add support for the DEC FDDIcontroller 700 (DEFZA), Digital Equipment
      Corporation's first-generation FDDI network interface adapter, made for
      TURBOchannel and based on a discrete version of what eventually became
      Motorola's widely used CAMEL chipset.
      
      The CAMEL chipset is present for example in the DEC FDDIcontroller
      TURBOchannel, EISA and PCI adapters (DEFTA/DEFEA/DEFPA) that we support
      with the `defxx' driver, however the host bus interface logic and the
      firmware API are different in the DEFZA and hence a separate driver is
      required.
      
      There isn't much to say about the driver except that it works, but there
      is one peculiarity to mention.  The adapter implements two Tx/Rx queue
      pairs.
      
      Of these one pair is the usual network Tx/Rx queue pair, in this case
      used by the adapter to exchange frames with the ring, via the RMC (Ring
      Memory Controller) chip.  The Tx queue is handled directly by the RMC
      chip and resides in onboard packet memory.  The Rx queue is maintained
      via DMA in host memory by adapter's firmware copying received data
      stored by the RMC in onboard packet memory.
      
      The other pair is used to communicate SMT frames with adapter's
      firmware.  Any SMT frame received from the RMC via the Rx queue must be
      queued back by the driver to the SMT Rx queue for the firmware to
      process.  Similarly the firmware uses the SMT Tx queue to supply the
      driver with SMT frames that must be queued back to the Tx queue for the
      RMC to send to the ring.
      
      This solution was chosen because the designers ran out of PCB space and
      could not squeeze in more logic onto the board that would be required to
      handle this SMT frame traffic without the need to involve the driver, as
      with the later DEFTA/DEFEA/DEFPA adapters.
      
      Finally the driver does some Frame Control byte decoding, so to avoid
      magic numbers some macros are added to <linux/if_fddi.h>.
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61414f5e
    • Serhey Popovych's avatar
      tun: Consistently configure generic netdev params via rtnetlink · df52eab2
      Serhey Popovych authored
      Configuring generic network device parameters on tun will fail in
      presence of IFLA_INFO_KIND attribute in IFLA_LINKINFO nested attribute
      since tun_validate() always return failure.
      
      This can be visualized with following ip-link(8) command sequences:
      
        # ip link set dev tun0 group 100
        # ip link set dev tun0 group 100 type tun
        RTNETLINK answers: Invalid argument
      
      with contrast to dummy and veth drivers:
      
        # ip link set dev dummy0 group 100
        # ip link set dev dummy0 type dummy
      
        # ip link set dev veth0 group 100
        # ip link set dev veth0 group 100 type veth
      
      Fix by returning zero in tun_validate() when @data is NULL that is
      always in case since rtnl_link_ops->maxtype is zero in tun driver.
      
      Fixes: f019a7a5 ("tun: Implement ip link del tunXXX")
      Signed-off-by: default avatarSerhey Popovych <serhe.popovych@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df52eab2
  2. 14 Oct, 2018 3 commits
  3. 13 Oct, 2018 28 commits