Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 5月, 2016 3 次提交
    • M
      IB/IPoIB: Allow setting the device address · 492a7e67
      由 Mark Bloch 提交于 
      In IB networks, and specifically in IPoIB/rdmacm traffic, the device
address of an IPoIB interface is used as a means to exchange information
between nodes needed for communication.

Currently an IPoIB interface will always be created with a device
address based on its node GUID without a way to change that.

This change adds the ability to set the device address of an IPoIB
interface by value. We use the set mac address ndo to do that.

The flow should be broken down to two:
1) The GID value is already in the GID table,
   in this case the interface will be able to set carrier up.

2) The GID value is not yet in the GID table,
   in this case the interface won't try to join the multicast group
   and will wait (listen on GID_CHANGE event) until the GID is inserted.

In order to track those changes, we add a new flag:
* IPOIB_FLAG_DEV_ADDR_SET.

When set, it means the dev_addr is a based on a value in the gid
table. this bit will be cleared upon a dev_addr change triggered
by the user and set after validation.

Per IB spec the port GUID can't change if the module is loaded.
port GUID is the basis for GID at index 0 which is the basis for
the default device address of a ipoib interface.

The issue is that there are devices that don't follow the spec,
they change the port GUID while HCA is powered on, so in order
not to break userspace applications. We need to check if the
user wanted to control the device address and we assume that
if he sets the device address back to be based on GID index 0,
he no longer wishs to control it.

In order to track this, we add an additional flag:
* IPOIB_FLAG_DEV_ADDR_CTRL

When setting the device address, there is no validation of the upper
twelve bytes of the device address (flags, qpn, subnet prefix) as those
bytes are not under the control of the user.
Signed-off-by: NMark Bloch <markb@mellanox.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NLeon Romanovsky <leon@kernel.org>
Signed-off-by: NDoug Ledford <dledford@redhat.com>
      492a7e67
    • E
      IB/ipoib: Support SendOnlyFullMember MCG for SendOnly join · 3b561130
      由 Erez Shitrit 提交于 
      Check (via an SA query) if the SM supports the new option for SendOnly
multicast joins.
If the SM supports that option it will use the new join state to create
such multicast group.
If SendOnlyFullMember is supported, we wouldn't use faked FullMember state
join for SendOnly MCG, use the correct state if supported.

This check is performed at every invocation of mcast_restart task, to be
sure that the driver stays in sync with the current state of the SM.
Signed-off-by: NErez Shitrit <erezsh@mellanox.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>
      3b561130
    • E
      IB/core: Introduce capabilitymask2 field in ClassPortInfo mad · 507f6afa
      由 Erez Shitrit 提交于 
      Change struct ib_class_port_info to conform to IB Spec 1.3
That in order to get specific capability mask from ClassPortInfo mad.

>From the IB Spec, ClassPortInfo section:
        "CapabilityMask2 Bits 0-26: Additional class-specific capabilities...
         RespTimeValue the rest 5 bits"

The new struct now has one field for capabilitymask2 (previously was the
reserved field) and the resp_time field.

And it fixes up qib and srpt, use of the field repurposed to be used as
capabilitymask2:
IB/qib: Change pma_get_classportinfo
IB/srpt: Adjust the use of ib_class_port_info
Signed-off-by: NErez Shitrit <erezsh@mellanox.com>
Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
Reviewed-by: NHal Rosenstock <hal@mellanox.com>
Signed-off-by: NDoug Ledford <dledford@redhat.com>
      507f6afa
  3. 14 5月, 2016 13 次提交
  5. 13 5月, 2016 8 次提交
  7. 06 5月, 2016 1 次提交
  9. 08 4月, 2016 1 次提交
    • B
      Revert "ib_srpt: Convert to percpu_ida tag allocation" · 3c968887
      由 Bart Van Assche 提交于 
      This reverts commit 0fd10721.

That patch causes the ib_srpt driver to crash as soon as the first SCSI
command is received:

  kernel BUG at drivers/infiniband/ulp/srpt/ib_srpt.c:1439!
  invalid opcode: 0000 [#1] SMP
  Workqueue: target_completion target_complete_ok_work [target_core_mod]
  RIP: srpt_queue_response+0x437/0x4a0 [ib_srpt]
  Call Trace:
    srpt_queue_data_in+0x9/0x10 [ib_srpt]
    target_complete_ok_work+0x152/0x2b0 [target_core_mod]
    process_one_work+0x197/0x480
    worker_thread+0x49/0x490
    kthread+0xea/0x100
    ret_from_fork+0x22/0x40

Aside from the crash, the shortcomings of that patch are as follows:

 - It makes the ib_srpt driver use I/O contexts allocated by
   transport_alloc_session_tags() but it does not initialize these I/O
   contexts properly.  All the initializations performed by
   srpt_alloc_ioctx() are skipped.

 - It swaps the order of the send ioctx allocation and the transition to
   RTR mode which is wrong.

 - The amount of memory that is needed for I/O contexts is doubled.

 - srpt_rdma_ch.free_list is no longer used but is not removed.
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3c968887
  11. 31 3月, 2016 1 次提交
  13. 22 3月, 2016 4 次提交
  15. 11 3月, 2016 9 次提交