1. 20 11月, 2021 2 次提交
  2. 30 10月, 2021 1 次提交
  3. 26 10月, 2021 1 次提交
  4. 26 8月, 2021 1 次提交
  5. 24 8月, 2021 3 次提交
  6. 04 8月, 2021 1 次提交
  7. 23 6月, 2021 3 次提交
  8. 22 6月, 2021 6 次提交
  9. 17 6月, 2021 1 次提交
  10. 09 6月, 2021 3 次提交
  11. 29 5月, 2021 2 次提交
  12. 20 5月, 2021 3 次提交
  13. 14 4月, 2021 4 次提交
  14. 09 4月, 2021 2 次提交
  15. 02 4月, 2021 5 次提交
  16. 26 3月, 2021 1 次提交
    • M
      RDMA: Support more than 255 rdma ports · 1fb7f897
      Mark Bloch 提交于
      Current code uses many different types when dealing with a port of a RDMA
      device: u8, unsigned int and u32. Switch to u32 to clean up the logic.
      
      This allows us to make (at least) the core view consistent and use the
      same type. Unfortunately not all places can be converted. Many uverbs
      functions expect port to be u8 so keep those places in order not to break
      UAPIs.  HW/Spec defined values must also not be changed.
      
      With the switch to u32 we now can support devices with more than 255
      ports. U32_MAX is reserved to make control logic a bit easier to deal
      with. As a device with U32_MAX ports probably isn't going to happen any
      time soon this seems like a non issue.
      
      When a device with more than 255 ports is created uverbs will report the
      RDMA device as having 255 ports as this is the max currently supported.
      
      The verbs interface is not changed yet because the IBTA spec limits the
      port size in too many places to be u8 and all applications that relies in
      verbs won't be able to cope with this change. At this stage, we are
      extending the interfaces that are using vendor channel solely
      
      Once the limitation is lifted mlx5 in switchdev mode will be able to have
      thousands of SFs created by the device. As the only instance of an RDMA
      device that reports more than 255 ports will be a representor device and
      it exposes itself as a RAW Ethernet only device CM/MAD/IPoIB and other
      ULPs aren't effected by this change and their sysfs/interfaces that are
      exposes to userspace can remain unchanged.
      
      While here cleanup some alignment issues and remove unneeded sanity
      checks (mainly in rdmavt),
      
      Link: https://lore.kernel.org/r/20210301070420.439400-1-leon@kernel.orgSigned-off-by: NMark Bloch <mbloch@nvidia.com>
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
      1fb7f897
  17. 12 3月, 2021 1 次提交